Χρόνια Πολλά σε όλους!
Εύχομαι ο νέος χρόνος να φέρει υγεία, αγάπη και ευτυχία σε εσάς και τις οικογένειες σας.
Αυτές τι μέρες βρήκα την ευκαιρία να διαβάσω αρκετά νέα βιβλία τα οποία είχα προμηθευτεί επί τούτου. Μέσα σε όλα αυτά ξεχώρισα τo παρακάτω εισαγωγικό σημειώμα που apriory με εκφράζει απόλυτα.
Με το που το διάβασα πετάχθηκα από το καναπέ μου και αναφώνησα ΠΕΣΤΑ ΧΡΥΣΟΣΤΟΜΕ. Χαίρομαι ιδιαίτερα όταν αυτά που και εγώ πιστεύω και διδάσκω είναι σύμφωνα με τα λεγόμενα ανθρώπων που είναι έγκυροι και καταξιωμένοι στην επιστημονική κοινότητα.
Ο εν λόγω κύριος είναι ο Paul Nielsen, SQL Server MVP με πάνω από 30 χρόνια φούρναρης εεε Database Specialist και συγγραφέας του SQL Server Bible http://www.sqlserverbible.com/. Ειδικά το υπογραμμισμένο κείμενο είναι κορυφαίο παράδειγμα για αυτούς που επιμένουν να θεωρούν την βάση σαν ένα κουβά.
Απολαύστε το
Any database can be evaluated on six basic criteria: usability, data integrity, scalability, extensibility, availability, and security. Of these database objectives, the first four are primarily driven by the design and development of the database.
One of the best practices that serves as a root cause for each of the four design driven goals is the elegance of the database design itself.
The trouble is that elegance of design can be an elusive creature—difficult to define, difficult to achieve, and difficult to teach. But we do know that at the core of every well-designed database are the principles of normalization. In the application development world, technologies are annual trends, but not so in the database world. Even after nearly 40 years, normalization—one grouping of things is one entity, one thing is one tuple, one fact is one attribute, and every attribute must describe the tuple—is still the foundation of database technology.
In the quest for elegance of design, the concepts of generalization and data driven design augment, but don’t negate, normalization. The war cry of the data architect is still, “The key, the whole key, and nothing but the key!” I am concerned, however, that database development skills—database design, normalization, and T-SQL—seem to be a dying art. In many shops, the lone data architect is outnumbered 50 to 1 by developers who don’t respect the
importance of data integrity. Managers listen to the crowd, and systems are designed for today rather than for next year, much less the next decade. The design methods and development tools used to encapsulate data should be at least as stable and live as long as the data. And data lasts a long, long time. Ask around, and
see how many DBAs manage data that’s 10, 20, or 50 years old. Most do.
The average lifecycle of a popular application development language is 3 to 5 years; a stored procedure written 20 years ago still runs (with maybe a slight tweak to the JOIN syntax).
I
picture the database as a granite rock that will last for an eon. Occasionally a UI developer comes along and paints a pretty chalk picture on the rock; it washes off and a few more UI developers add their pictures. They all wash off with time, but the rock remains. OK, it’s a stretch, and I do like a great UI, but the point is that any IT architecture should be founded on data integrity.
1 Comment
Recommended Comments