What does the R in Relation Database stand for?


A couple of days I was working on pushing some business forms out for users to enter some business data into our db. I have been at my current company for about 4 months and due to our busy season and my minimum understanding of business rules and already existing libraries used, i hadn’t had the time to get an end to end processing of data from the client-end down to the db. Well, I finally got down to the DAL using our custom DAL libraries and boom, i realized that the DAL allowed me to enter a child row in one of the tables without a parent entered as yet. I was shocked. How is that suppose to happen so I folded my sleeves and put on my SQL hat. A nanosecond into looking at the db, i realized that there were no constraint or relations on the tables. They were just free standing table. I panicked, called for a meeting with my team to find out why. This was the answer
“The database is an object persistence storage and not a relation database”.
It took me a while to understand the direction they were coming from which probably exist in the J2EE world where most of the business logic and rules are lifted to the Business and Data Layer. I still get shivers when i think of it. That brought me to the bigger question,
“What does the R in Relation Database stand for?”.
For people like me who build application from database upwards which is what code generation tools like Codesmith and Linq rely on to also generate your DAL, it was hard to reverse the direction and go from UI, BAL, DAL to just Business Object Persistence db. I still will build up in the heart beat because the db is the final line for your process and it integrity does not exist in the db, human/developer error in code will filter down to the db. What you end up getting is a DB with many orphan’s and more. Im getting use to doing it from top to bottom now and we will be migrating to fully relation db next year after we roll out our current version.