That would be the obvious solution if the data is object-oriented - but it's not necessarily so. In my own case, over the last ten years I have been working more often than not with timestamp data, both in regard to realtime market pricing and mobile 'phone billing. Either way, neither the relational nor object-oriented model is ideal for storing and processing the data and relational tends to be used as a sort-of default architecture.
For example, in the case of the billing, it stays in record form as long as possible during the algorithm where Perl rips through like a knife through butter. But eventually the huge 6-million record customer database is needed for lookup and the records have to be split into batches and processed slowly 100 at a time (and that's for best performance) while it trundles through the stored procedure processing before Perl could get its hands on it after that to finish the job off. The ineffectiveness of the relational architecture is costing the operators serious money and an object architecture would not in fact come to the rescue.
| [reply] |
The problem you're describing (slow stored procedures) sounds more like an implementation problem than an intrinsic limitation of relational databases.
| [reply] |
I suppose you could say it's an implementation problem, in the sense that theoretically a relational database doesn't need to construct temporary cross-product sets to achieve a join, causing execution time to be proportional to the product of the rowcounts, but in practice it appears to be an inescapable one.
| [reply] |