This content has been marked as final. Show 116 replies
Out of context this reads like the sort of pseudo-profound gibberish that the Bene Gesserit spout in Dune. Alas, as none of the posts in this thread mentions "storage" (least of all Erk's) the precise context intended by Erdem remains elusive.
the storage and business could affect each other but they are not the mirrors of each other.
Still, it's fun this, innit.
This thread is still alive?
Out of context this reads like the sort ofI'd have voted for "The Sphinx" in "The Mystery Men". ;-)
pseudo-profound gibberish that the Bene Gesserit
spout in Dune.
Alas, as none of the posts in thisAnd that's not the only thing in this thread ...
thread mentions "storage" (least of all Erk's) the
precise context intended by Erdem remains elusive.
Still, it's fun this, innit.And it seems quite familiar, if you are a badtech, dilbert or userfriendly reader.
The user interface is STILL ruled by the "performance and scalability" considerations for the database,which makes the code behind >>> "disk" performance based code...
that is a normal thing.I guess u guys really like to select the data where u have already inserted and updated.The two main tables are mainly for inserts,updates and deletes.
if u need some sort of SELECT performance it is better to put it into a concrete table just for that problem.Don't be afraid to duplicate the data in those concrete tables if u have the core two table system in place.
Now you're really scaring me. All these years I've been working to avoid replication (i.e. duplication) wherever possible because it's a flipppin' nightmare to administer/maintain and now you're proposing that we use materialized views (or whatever) in order to handle performance bottlenecks in a shonky data model instead of building a decent data model??? Fnord.
Don't be afraid to duplicate the data in those concrete tables if u have the core two
table system in place.
Keep 'em coming! APC
I guess the main issue about this design is "joins" it causes in the relational system.
but if u look deeply into the problem the normalization process also creates joins inorder the avoid dublicate data.
I guess oracle designer approach is right for designing applications but u need performance u can write the concrete data model version all with procedural programming but u should do tihs after u discover "what" u have to do with the object model.
I don't want an overthrown but a balance.After :I complete the the requirements other than performance,I am willing the write all the application from gorund up for the relational database for performance even though that procedural application has a no "reuse".
it is a matter of decision as oracle did its designer...