This is a continuation of my whining against the relational model.

Yes, I realize that it is efficient and its theoretical background is
elegant, nay, beautiful. I read all about it when I was in college.

The problem is like trying to put a round peg in the proverbial square
-actually: rectangular- hole.

We deal with many different companies and have to replicate their
database structure. A feature that comes to mind is the variable
'struct' in C. IIRC Oracle supports something like that. I envision a
table whose fields are divided in two classes:

- common fields, which are used by all instances of such table
- a variable (or "custom" for lack of a better term) part which is
specific to each case.

I would like to re-use the programs (I program with the Pro C
precompiler). across the "variant" tables.

TIA,

GP

"Google Poster" <goposter (AT) jonjay (DOT) com> wrote

All tables are "variable", ie. table structure is dynamic rather than fixed.
Schema change is the norm in many if not most databases and the only
question is how you manage that change (essentially a management problem
rather than a technical one).

--
David Portas

On Sep 4, 2:43*am, "David Portas"
<REMOVE_BEFORE_REPLYING_dpor... (AT) acm (DOT) org> wrote:
I believe we have a time scaledifference as to what constitutes
dynamism:

- You are referring to table structure (its fields) changing from one
year to the next. What you are essentially saying is that the only
tables ever that remain constant are those given by God to Moses.
People don't put those kinds immovable stuff in software (hardware
perhaps).

- I am referring to the table structure changing from a millisecond
to the next. In a tight loop, the table is seen as having certain
structure, and next iteration it is seen as different. That is a
technical issue.

In my C example I should have used the word "union".

-GP

On Sep 4, 4:14*am, Google Poster <gopos... (AT) jonjay (DOT) com> wrote:
I work on a system that allows different customers to have different
layouts, and the system adapts somewhat. The downsides are it has to
do some level of lowest-common-denominator across database engines
(which also means it avoids lots of bugs associated with newfangled
features, as well as tuning issues), and it requires keeping
additional metadata, which implies issues of synchronization and other
stupidity like http://richardfoote.wordpress.com/20...n-keys-helden/
(in this case, the opposite problem - no primary keys!).

It works surprisingly well, considering, and also shows where the
value lies - in the application code. Having worked on this app code
and the language involved for many years, I, at least, am convinced
that one should use the features of the database appropriate to your
app, and not try too hard to generalize things. Simply make it easy
to customize for customers, so you can amortize the costs over many
customers and receive revenue for differences. You don't want to try
to define everything down to the hardware layer, that's a real C-
programmer mistaken viewpoint. You want to add some layers of
abstraction, and be able to minimize the calls to the hardware layer,
then optimize those. Think about the Exadata architecture.

Adding the ability to deal with table structure changing by the
millisecond implies adding design constraints for technical reasons,
leading to bad physical design. Stupid in multi-user situations,
which most business situations that require a database are.

jg
--
@home.com is bogus.
http://www.guardian.co.uk/technology...loud-computing

You should choose the right tool for the right job.
If you have semistructured and schema chaos, perhaps XML and XQuery are
better answers than trying to bang relational into a shape that it is not.
A compromise may be found in table hierarchies... (aka typed tables)

Cheers
Serge

--
Serge Rielau
SQL Architect DB2 for LUW
IBM Toronto Lab

On Fri, 4 Sep 2009 04:14:38 -0700 (PDT), Google Poster
<goposter (AT) jonjay (DOT) com> wrote:


So you should concentrate on developing the GDBMS, the Garbage
Database Management System, though I believe someone already invented
XML for that purpose.

--
--
Sybrand Bakker
Senior Oracle DBA

On Fri, 04 Sep 2009 04:14:38 -0700, Google Poster wrote:


Here is how things work: you pick a programming paradigm and then use it.
If all you have is a relational theory, then every problem looks like it
could be solved by a database. You can not use RDBMS like a Petri network
or Forth. It's not the same. You are probably missing an object or two.



--
http://mgogala.freehostia.com

On Sep 4, 6:33*pm, Mladen Gogala <mla... (AT) bogus (DOT) email.invalid> wrote:
You are close, but my problem is not exactly as described. First of
all, along the years I have made a heavy of investment on Oracle. Not
necessarily in money terms, but the really valuable resources: time,
knowledge, access programs, reading this NG :-) etc.

Initially it was not too hard to design simplistic tables and write
access programs. As time goes by, those schemas need to be more
complex, and I start having doubts of whether there are other
approaches and solutions.

I guess I need to hire a real DBA, but can't afford it now...

-GP