Andmebaasidest
Digg-i kaudu sattusin developer.com artiklile http://www.developer.com/db/article.php/10920_3589351_1.
Ma tahaks sealt 2 asja välja tuua:
I’ve seen a lot of teams go down the rat hole of database independence, writing layers to translate all of their SQL statements to some lowest common denominator dialect that every conceivable database will support, and at the same time giving up on advanced features available in any particular database. The notion seems to be that some client in the future might want to switch to Oracle or DB2 or FoxPro or whatever, so it’s best to be prepared now. On the contrary: when you’re starting out with a new product, pick your storage engine and write to it. If your product is good, people will install the database you specify, and you won’t be wasting untold man-hours supporting “just in case” scenarios that you’ll probably never need.
See on mind igasugu abstraktsioonikihtide juures kõige rohkem häirinud siiani – nii mõnigi aastate ja aastakümnete jooksul arendatud, projekteeritud ja optimeeritud andmebaasiserver on implementeerinud tõsiselt häid võimalusi ja abstraktsioonikiht ei lase sul neid kasutada – pead kõiki toetatavate baaside minimaalse ühisosaga leppima.
Ja teine.
Stored procedures and triggers are a wonderful thing. When you’ve got multiple clients accessing a database, they can be a great way to make sure consistent data processing takes place. But they can also turn into an ugly black box in which application logic hides, unknown to Web and thick client developers, generally unseen and unreviewed. Too often database code isn’t subject to the same standards of design, test, and code review that we demand for the rest of our applications. When you’re tempted to put code in the database, take a moment to ask yourself whether it really belongs there.
. Siin on kah point sees, liiga palju loogikat ei tasu andmebaasifunktsioonidesse panna.
Sorry, comments are closed.