What if you had to do everything a SQL Query Plan generator does? Well,, that’s how it was back in the dark ages. You had a lot of control over performance, but the complexity it added was quite cumbersome.
In the old days, data wasn’t stored in relational tables. Depending on the data engine, the data was organized quite differently. Sometimes data was stored in a few files. The data was denormalized. Child data was stored in parent
records with repeating column names like DependentName1, DependentName2, DependentName3. If you had more dependents than the number of dependents defined in an employee table, you’d have to create another linked record, adding to the complexity of your application.
Other databases stored data hierarchically. You would have an employee record, and dependent records attached to that employee record. There was not a separate dependent table; you found dependent data by navigating through each employee. This worked really nice until you needed to ask a question such as, how many dependents do our employees have that are under the age of 1?
In those days we had a huge volume of manuals for programs designed to find and sort your data. The sort manual itself on one system I worked on as about a foot thick. In essence, using filtering and sorting utilities, you would build your own query plan for your program. You’d find the best search tool for the data design, and you knowledge of the data domain. You could also select from many different sort routines, each with different performance characteristics.
Once you pre-processed your data, performing filters and sorting, you could bring the data together to exercise your logic. Today, your SQL engine does all of this for you. It determines what index or indexes to use to locate your data,
pulls data together from different tables, executes efficient sort routines, and returns the results in an easy to use format.
Anyone want to go back to the old days? As for me, I’m enjoying SQL.
Cheers,
Ben