Why your app’s database stinks— and your ORM too
-
At the dawn of the millennium, somewhere in the depths of a company contracted by the United States Navy, D. Richard Hipp designed SQLite so that you could finally stick a database inside an application.
Ignore the fact he's trying to sell you a competitive product. I'm sure that's just a coincidence.
-
At the dawn of the millennium, somewhere in the depths of a company contracted by the United States Navy, D. Richard Hipp designed SQLite so that you could finally stick a database inside an application.
Ignore the fact he's trying to sell you a competitive product. I'm sure that's just a coincidence.
-
At the dawn of the millennium, somewhere in the depths of a company contracted by the United States Navy, D. Richard Hipp designed SQLite so that you could finally stick a database inside an application.
Ignore the fact he's trying to sell you a competitive product. I'm sure that's just a coincidence.
ORMs are members of that class of "solutions" that are designed to keep newbies from learning to do things the right way.
-
At the dawn of the millennium, somewhere in the depths of a company contracted by the United States Navy, D. Richard Hipp designed SQLite so that you could finally stick a database inside an application.
Ignore the fact he's trying to sell you a competitive product. I'm sure that's just a coincidence.
Glad to see Realm works perfectly with C++... oh, wait.
-
At the dawn of the millennium, somewhere in the depths of a company contracted by the United States Navy, D. Richard Hipp designed SQLite so that you could finally stick a database inside an application.
Ignore the fact he's trying to sell you a competitive product. I'm sure that's just a coincidence.
Hmmm, I have to say that article was poor. It stated that there was a problem, detailed what the author thought the problem was and.... well, that was it. If he'd taken it just that one step further, he could have talked people through how to solve the problem of poor performance; for instance, he could have made it explicit that you shouldn't do multiple updates when they should be set based operations.
This space for rent
-
ORMs are members of that class of "solutions" that are designed to keep newbies from learning to do things the right way.
I have no dislike for writing SQL and stored procedures at all. SQL Management Studio has auto completion and it's pretty comfy. And if things don't work as you expect you can debug it inside SQL management studio too, good luck doing that with your ORM. Performance is great too. For basic CRUD access I've written my own stored procedures that generate CRUD stored procedures (in SQL you can query table and column metadata and generate output based on that), so for 90% of the things I need I can generate it, and the other 10% I can generate it and tweak to my needs.
Wout
-
ORMs are members of that class of "solutions" that are designed to keep newbies from learning to do things the right way.
-
Hmmm, I have to say that article was poor. It stated that there was a problem, detailed what the author thought the problem was and.... well, that was it. If he'd taken it just that one step further, he could have talked people through how to solve the problem of poor performance; for instance, he could have made it explicit that you shouldn't do multiple updates when they should be set based operations.
This space for rent
I completely agree with you. In fact, there are ORMs that allow set based operations (the WHERE part of a LINQ select can very well be used in an update).