Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The very first thing developers should know about databases is this: <strong>what are databases for</strong>? Not how do they work, nor how do you build one, nor even how do you write code to retrieve or update the data in a database. But what are they for?</p> <p>Unfortunately, the answer to this one is a moving target. <strong>In the heydey of databases, the 1970s through the early 1990s, databases were for the sharing of data.</strong> If you were using a database, and you weren't sharing data you were either involved in an academic project or you were wasting resources, including yourself. Setting up a database and taming a DBMS were such monumental tasks that the payback, in terms of data exploited multiple times, had to be huge to match the investment.</p> <p><strong>Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application.</strong> Building a database for <a href="http://en.wikipedia.org/wiki/MySQL" rel="noreferrer">MySQL</a>, or <a href="http://en.wikipedia.org/wiki/Microsoft_Access" rel="noreferrer">Access</a>, or <a href="http://en.wikipedia.org/wiki/Microsoft_SQL_Server" rel="noreferrer">SQL Server</a> has become so routine that databases have become almost a routine part of an ordinary application. Sometimes, that initial limited mission gets pushed upward by mission creep, as the real value of the data becomes apparent. Unfortunately, databases that were designed with a single purpose in mind often fail dramatically when they begin to be pushed into a role that's enterprise wide and mission critical.</p> <p>The second thing developers need to learn about databases is the whole <strong>data centric view</strong> of the world. The data centric world view is more different from the process centric world view than anything most developers have ever learned. Compared to this gap, the gap between structured programming and object oriented programming is relatively small. </p> <p>The third thing developers need to learn, at least in an overview, is data modeling, including conceptual data modeling, logical data modeling, and physical data modeling.</p> <p><strong>Conceptual data modeling</strong> is really requirements analysis from a data centric point of view.</p> <p><strong>Logical data modeling</strong> is generally the application of a specific data model to the requirements discovered in conceptual data modeling. The relational model is used far more than any other specific model, and developers need to learn the relational model for sure. Designing a powerful and relevant relational model for a nontrivial requirement is not a trivial task. You can't build good SQL tables if you misunderstand the relational model.</p> <p><strong>Physical data modeling</strong> is generally DBMS specific, and doesn't need to be learned in much detail, unless the developer is also the database builder or the DBA. What developers do need to understand is the extent to which physical database design can be separated from logical database design, and the extent to which producing a high speed database can be accomplished just by tweaking the physical design.</p> <p>The next thing developers need to learn is that <strong>while speed (performance) is important, other measures of design goodness are even more important</strong>, such as the ability to revise and extend the scope of the database down the road, or simplicity of programming. </p> <p>Finally, anybody who messes with databases needs to understand that <strong>the value of data often outlasts the system that captured it</strong>.</p> <p>Whew! </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload