4 ms·
But once you have run the stored proc how do you display it to the user? How do you get the data from the UI to the stored proc to execute? You write some code
by craigvn 10y ago
But once you have run the stored proc how do you display it to the user? How do you get the data from the UI to the stored proc to execute? You write some code or it happens by magic? If you write some code, then you have just written an ORM.
- deleted 10y ago[deleted]
- dhd415 10y agoIt's overly reductive to consider any code that interacts with a database an ORM. Broadly speaking, the big claims ORMs have made are 1) the ability to automatically map between an object model and a relational data model and 2) portability between database vendors. #1 falls apart when the object model becomes complex enough to suffer from object-relational impedance mismatch. #2 may work for smaller or simpler applications, but you're generally going to have to take advantage of vendor-specific database features to achieve optimal performance with applications that have anything more than trivial scale or performance requirements. Going with stored procedures generally means giving up on both #1 and #2 in exchange for a more flexible design (relational model can be very different from your object model) and higher performance (at the cost of having to hand-write all your own SQL, of course).
- PeCaN 10y ago> If you write some code, then you have just written an ORM. What? No, I've written code to query a database. Not an Object-Relational Mapper. my $q = $db->prepare("get_my_stuff_by_name(?);"); $q->execute($name); or with fancy metaprogramming: use DBMagicStuff 'postgres://…'; get_my_stuff_by_name($name); That's not really an ORM.
- intrasight 10y agoYou are both partially right. An ORM deals with the black magic of connections, parameters, transactions, etc. If you don't use an ORM, then you still have to deal with those semantics. But I do agree that you aren't writing an ORM.
- PeCaN 10y ago> connections, parameters The database driver takes care of that, not the ORM. (It's also not black magic.) > transactions Huh? That's a database feature. BEGIN/COMMIT/ROLLBACK are ANSI SQL. ORM is an _Object Relational Mapper_. You're confusing it with a database driver (or, in the case of transactions, just a database in general).
- mixedCase 10y agoIn Go I only need to annotate the column name of the struct variable to have it load automagically from DB using just SQL and a little bit of tooling (sqlx). 95% of the convenience of an ORM, none of the problems.
- manigandham 10y agoThat's because sqlx (and the go foundation) are already a basic ORM.
- mixedCase 10y agoYou could argue that anything that interfaces with a database is an ORM, but it is certainly no ORM in the Hibernate/ActiveRecord/EntityFramework sense. It does very little "magic" and you're in full control of the SQL from the start.
- manigandham 10y agoSure, let's say an ORM is anything capable of turning normal app code into SQL statements by itself. What do ORMs do that's magic? What are the problems? Are you not in full control of them? It's your code after all that's using them. I really don't get how they suddenly force any issues on you that you don't create yourself. The output SQL doesn't really matter if it gets the job done, and in cases it does you still have full control to write it yourself, and even use the same ORM to save you time in executing that.
- mixedCase 10y ago>What do ORMs do that's magic? What are the problems? Are you not in full control of them? It's your code after all that's using them. http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
- deleted 10y ago[deleted]