7

I work on a pretty old application which was converted from DOS and flat files for storing information to Paradox tables using the BDE then to MySQL relational database.

The older devs say that the reason they have no idea how to properly create a table in 3nf is because their code predates relational databases and they never learned about them in school.

So, within actual programs, when did a majority of programmers adopt a decent method for creating tables in their databases? If you look at the databases in open source CMS's, those tables look well normalized - are successful ones initiated that way or do they get normalized over time (or denormalized for pragmatic reasons)?

Improve this question
10
  • 18
    ...they never learned about them in school and never bothered to read a book or an article in the intervening years? I hope for your sake those older devs are no longer writing code. Commented Jul 18, 2011 at 19:01
  • 4
    How old are these guys?! I went to school in the mid-80's and it was taught then, and I didn't stop learning when I graduated, either. I'm 50 -- are they in their 70s and 80s? Commented Jul 18, 2011 at 19:36
  • 9
    Given the number of people who use SQL without ever taking a class in the subject, thats sort of a BS excuse on their part. Commented Jul 18, 2011 at 19:39
  • 1
    A math major? Did he skip his relational algebra classes? Commented Jul 18, 2011 at 20:49
  • 1
    TBH, I find it odd that in all those decades they didn't get what the advantages of having tables in 3NF was, even not knowing what 3NF was. A lot of people have tables in 3NF without knowing it, just because it's what feels right. Commented Jul 18, 2011 at 21:52

8 Answers 8

Reset to default
17

The relational model was first formulated by E.F. Codd in 1969, and was first implemented in various IBM databases in the '70s. It also looks to me like the first edition of C. J. Date's seminal "An Introduction to Database Systems" was published around 1974.

I was hearing noise about relational databases in the 80s, without even paying much attention. Oracle, Ingres, and Informix were all shipping server-oriented commercial relational databases in the early 80s and doing quite nicely at it.

As for when relational databases were widely used on microcomputers,, well... that's another matter. The most popular microcomputer databases back in the 80s were decidedly not relational - this would include dBase, FoxPro, FileMaker and Paradox.

I would say the transition toward relational databases on microcomputers generally occurred during the 90s, as the ability to network to relational databases hosted on servers became common. It certainly did for me - at the beginning of the decade, I would look rather blankly at people who mentioned relational databases, and by the end of the decade, I was frustrated at having to work with FileMaker (as opposed to Informix, Oracle, or MS Access) because it wasn't sufficiently relational and didn't support SQL.

Improve this answer
2
  • This answer fits the timeframe. We hopped on SQL really quick, but missed the boat on normalization. Commented Jul 18, 2011 at 19:42
  • Sounds about right. I was in school in the early 80's and we were taught normalization. Commented Jul 19, 2011 at 8:45
3

As others have pointed out, relational database theory including the basic normal forms was developed in the 70s. By the 80s, relational databases like DB2 and Oracle were in widespread use on mainframes. The first PC databases like dBase were not relational, and I could understand PC programmers who'd cut their teeth on dBase back in 1984 not knowing about the various normal forms, but relational databases like Sybase and MicroRIM were available on PC's by the late 80's, and by the late 90's relational databases had pretty much crowded out the traditional dBase products except for legacy applications. Certainly by 1993 any decent college level class on databases would have covered the normal forms in detail.

Improve this answer
2
  • I can give one data point to support this - the class on databases I did at uni in 1992 covered normal forms (iirc, we were using Sybase SQL Server on SunOS, for what it's worth). Commented Jul 19, 2011 at 0:54
  • dBase descendants were heavily used in the PC world well after the late 90's. Commented Nov 1, 2011 at 11:21
2

Well... at least since the 80's. I got my training at a well-known Software company in the Netherlands and way back then we were all taught about data normalisation. Normalisation probably has been around just as long as relational databases, which originated in the early 70's.

Improve this answer
2

Quoted from Wikipedia :

Edgar F. Codd, the inventor of the relational model, introduced the concept of normalization and what we now know as the First Normal Form (1NF) in 1970. Codd went on to define the Second Normal Form (2NF) and Third Normal Form (3NF) in 1971, and Codd and Raymond F. Boyce defined the Boyce-Codd Normal Form (BCNF) in 1974. Higher normal forms were defined by other theorists in subsequent years, the most recent being the Sixth Normal Form (6NF) introduced by Chris Date, Hugh Darwen, and Nikos Lorentzos in 2002.

As for the decency of the method used to create database, normalized or not, a lot of people would say that as long as it works and performs at a satisfying speed and accuracy, it's a decent solution. Maintenance is the real point, and as you point out, sometime it's better to normalize, sometime it's better to denormalize.

Scott Ambler has written a good book about database maintenance : Agile Database Techniques: Effective Strategies for the Agile Software Developer. It's possible to refactor databases, and improve them, not as easy as code, but there are ways.

Improve this answer
4
  • I can live with never-normalized databases, the real problem is when I write my own tables and I want them to be normalized, they stick out like a sore thumb because they don't fit the mold (i.e. there is usually only one primary key instead of 4-5) Commented Jul 18, 2011 at 19:05
  • @Peter Turner - do you want to do it right or be like everyone else? They should stick out; so what. Commented Jul 18, 2011 at 19:28
  • @Jeff O, there's a difference between sticking out and writing code to easily work with databases. I've had more trouble writing code to use my own tables in a general way because I write the code to use the pre-existing core tables first. For instance, if I have some ID that is the primary key in one table, an a part of the primary key in another table where I'd have made it a foreign key. I can't depend on autoinc and I can't insert without checking all the keys. The way they write code is OK (meaning all problems can be solved with extra code) but by no means optimal. Commented Jul 18, 2011 at 19:36
  • 1
    @Peter Turner : consistency vs evolution - that's almost always a tough one. Especially with large enough code base and different views regarding architecture inside the team. Commented Jul 18, 2011 at 21:14
2

Relational databases have been around for a while, and normalization, while nice for simplifying your data model, is really REALLY nice for conserving disk space. I've never used a system that wasn't at least 1NF, and I work on a lot of pre-1980 legacy crap.

Hell, the standard normal forms were mostly set down in the 1970's...Some of them were set down before 1974, which was the year IBM put out the first SQL spec, and around when RDMS was released.

So yea, normalization has been there from the very beginning.

Improve this answer
1

Third normal form has been around for awhile. I'm not sure you can really put a date on when developers suddenly got religion. The database designers would have had to incorporate relational design in their products before that, and now the "new religion" of NoSql databases turns the whole notion of relational design on its ear.

It's better to have a good database design from the start. Changing the database structure after the application has reached a non-trivial size is difficult; you have to write programs that translate from the old database schema to the new one, and that takes time and resources away from application improvement efforts.

So I would say that the most successful projects are the ones where the database design is well thought-out before the development effort has begun in earnest.

Improve this answer
1

A big part of it also depends on WHERE they are from as well.

Take me for an example. I started developing in the late 80s and in my part of the world (Malaysia), RDBMs didn't really start making the rounds until the early 90s or so.

Most magazines you could order back then were hardware related and book selection was depressing to say the least. The internet also wasn't anything close to what it is now and trying to get consistently reliable information regarding products and advances was impossible. These all conspired to make self learning hard when it comes to new technology.

The other avenue to learning was through local colleges but that didn't work out as well since colleges in most 2nd/3rd world countries would not introduce new concepts into graduate courses until they were "proven".

Some of us normalized because it just made sense. Some of us normalized by "accident". Some of us who retired early still don't know what normalization means :P

In any case, if I had to put a date to it, I'd say mid 90s was when everyone jumped on the "normalize or die" bandwagon in my part of the world.

BTW, no one should think ill of them regardless of when (if ever) they picked up normalization because it truly was a different world back then.

Improve this answer
1
  • I appreciate the reality of your answer and the perspective. One of the two founding developers of our application got his education in the Soviet Union. Commented Jul 19, 2011 at 13:08
0

I have no idea when their university started to offer courses in relational db's or made it a requirement. Based on the other repsponeses (1969-1970), rdbms predates DOS (1981), so how did they manage to learn that?

You need to determine where normalizing your database is going to benefit your application. Once they see some examples in a database and application that they are very familiar with, they should be able to pick it up.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.