tag:blogger.com,1999:blog-6104420435021904082.post4121837849705427180..comments2024-03-13T12:21:27.016-05:00Comments on The Programmer's Paradox: Structuring Noun & Verb DataPaul W. Homerhttp://www.blogger.com/profile/02349253120538728302noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6104420435021904082.post-21204087792369655672008-06-12T11:14:00.000-05:002008-06-12T11:14:00.000-05:00Hi Anonymous,No worries, ease of access allows for...Hi Anonymous,<BR/><BR/>No worries, ease of access allows for inaccuracies :-)<BR/><BR/>I fixed it, although a language that completely turns around is probably more expressive than a database as well :-)<BR/><BR/>Paul.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-28544298071661000372008-06-12T10:26:00.000-05:002008-06-12T10:26:00.000-05:00Nitpick: "Turning complete" ?This time on the righ...Nitpick: "Turning complete" ?<BR/>This time on the right place (sorry).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-77109297325799836662008-06-12T10:20:00.000-05:002008-06-12T10:20:00.000-05:00Hi JS,The noun/verb (quasi-relational) structure i...Hi JS,<BR/><BR/>The noun/verb (quasi-relational) structure is relatively 'static', in that once you've created it, the number of tables isn't changing. The equivalent relational database is constantly changing (increasing) in table size because the arbitrary structures essentially will cover some subset of all of the possible permutations. <BR/><BR/>Since we can generate the views, based on the underlying data, and we have to do this constantly, it is easier (probably) to anchor the static abstract structure to the lower-level mechanics (tables), and the dynamic (changing) size to the higher level (views). <BR/><BR/>Going the other way, we'd have more work to create new tables on the fly when we've encountered some new type of data-structure. The synchronization qualities would be better, but 'adds' could be really slow and undependable.<BR/><BR/>Mostly reporting and ad-hoc queries are read-only anyways, so accepting some type of 'drift', but maintaining performance isn't too painful for a trade-off.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-42821340597959190702008-06-11T15:59:00.000-05:002008-06-11T15:59:00.000-05:00Since the database structure that the ad-hoc query...Since the database structure that the ad-hoc query and reporting tools want is more complicated than the quasi-relational model you describe, why not implement the quasi-relational model as a set of updatable views into all the sub and sub-sub tables? That would also solve your problem of having to synchronize the quasi-relational tables from the tables required by more traditional database tools.Anonymousnoreply@blogger.com