2 Responses to Data Structures — Tabular vs. Relational

  1. I am facing exactly the problem that you described here. I am working on a swimming pool maintenance log application. First I tried to model my data with relational constraints, but I soon realized that is pushing an apple through a key hole. I am now looking for a more appropriate data store and model. My domain seems to be perfect for duck typing. I hope ending up with about 10 types of building blocks instead of 20 hierarchical tables. My next challenge is to find a duck type data store. Do you have any recommendations?

  2. Klaus,

    I’m not entirely clear what you mean by perfect for duck typing but I’m assuming that the building blocks you describe can be thought of as objects. The first thing that comes to mind is to use Object Relational Mapping software to work with your objects as objects and let the ORM deal with storing them in an RDBMS.

    Taking a step back, though, I have to ask how much data you can possibly have if each row corresponds to a swimming pool maintenance visit. Can you possibly generate more than 100,000 visits per year? That’s just not that much data unless you have truly voluminous metadata for each visit. Why not just have rows store as much of the metadata as possible in a single table and then have a very few related tables for the wordy metadata. As mentioned above, it’s not against the law to store oft-repeated metadata in additional columns. You could store the whole thing in an SQLite database for easy deployment and maintenance.