XWiki DB Schema Architecture

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

XWiki DB Schema Architecture

Jim Stuttard-2
Hi,

As tempus fugit towards release 1.0 I have a bit of a basic architecture
problem with the current DB schema.

Why does XWiki's DB schema depend on a number of proxy primary keys - eg.
ID: bigint? XWikiListClasses has a primary key of id, and name;
XWikiClasses has only a numeric id and name doesn't seem to matter. Is
this just me missing some basic idea?

Doesn't this hide the cardinalities, semantic connections and
non-transitive dependencies captured by primary keys in a fully-normalised
relational schema?

Currently this information would have to be inferred from the existing
schema, taking some time to do. And so I can't tell whether the schema is
normalised or not.

An example might be a Document. If memory serves me, Documents are
frequently uniquely identified by the minimal primary key of {title,
author, publication date}. If you ask "What are the chances of 2 different
documents having the same author name, title and publication timestamp?"
then this satisfices most conditions. An XWikiDoc however has a large set
of required fields and a single key.

Neither MySql nor any other RDBMS I know of uses single-field primary
keys. They are only required in the binary relational model.

I have always thought that good OODB design demanded *explicit*
de-normalisation if needed?

Cheers

Jim

--
Jim Stuttard



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: XWiki DB Schema Architecture

zuzur
Hello Jim,

i think most of this denormalization and key duplication comes from the fact that we (ludovic and myself) had *very bad* experiences with integrity constraints in some systems where updating (removing rows, etc ...) the database in a timely manner was critical. Respecting the correct removal/update order in order to have the constraint cascading appropriately is a real challenge in itself, and we tend to think it is better to rely on the application to maitain data integrity. I personally know this is a major sin regarding proper application design, and much worth as OOD comes into the game.

I've been using O/R mappings frameworks (one we designed from scratch when there was no such thing around in the market) for years, and tend to think they don't mix well when the schema has integrity constraints. I'm not familiar enough with hibernate to give a definitive judgement, and will happily be proven wrong :)

Now if you want to work on the current database schema so it follows all normalization levels, you'd be most welcome, and i'd happily give a hand !!!

Erwan

On 11/4/05, Jim Stuttard <[hidden email]> wrote:
Hi,

As tempus fugit towards release 1.0 I have a bit of a basic architecture
problem with the current DB schema.

Why does XWiki's DB schema depend on a number of proxy primary keys - eg.
ID: bigint? XWikiListClasses has a primary key of id, and name;
XWikiClasses has only a numeric id and name doesn't seem to matter. Is
this just me missing some basic idea?

Doesn't this hide the cardinalities, semantic connections and
non-transitive dependencies captured by primary keys in a fully-normalised
relational schema?

Currently this information would have to be inferred from the existing
schema, taking some time to do. And so I can't tell whether the schema is
normalised or not.

An example might be a Document. If memory serves me, Documents are
frequently uniquely identified by the minimal primary key of {title,
author, publication date}. If you ask "What are the chances of 2 different
documents having the same author name, title and publication timestamp?"
then this satisfices most conditions. An XWikiDoc however has a large set
of required fields and a single key.

Neither MySql nor any other RDBMS I know of uses single-field primary
keys. They are only required in the binary relational model.

I have always thought that good OODB design demanded *explicit*
de-normalisation if needed?

Cheers

Jim

--
Jim Stuttard




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto: [hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: XWiki DB Schema Architecture

Jim Stuttard-3
On Sun, 06 Nov 2005 12:04:02 -0000, Erwan Arzur <[hidden email]> wrote:

> Respecting the correct removal/update order in order to have the  
> constraint cascading appropriately is a real challenge > in itself, and  
> we tend to think it is better to rely on the application to maitain data  
> integrity.

Always the hardest problem and some consider some kinds of referential  
integrity to be business rules. However good old Codd's laws reduce the  
complexity of updates and deletes.

> Now if you want to work on the current database schema so it follows all  
> normalization levels, you'd be most welcome, and i'd happily give a hand  
> !!!

It's about time I did something useful. It seems worth asking whether  
you've considered keeping *all* assets with the as static data in a RDBMS  
(eg the famous Oracle BLOBS for movies)? I'd expect a DB Schema update  
every time a new service is added, even if it's database called "cache".

I've been stealing use cases from as many sources as I can and have  
started sketching odd aspects in RelaxNG(compact) towards some core,  
generic wiki.

I'm absorbed at the moment in Alloy: integrating it into  
round-trip-engineering and automatic test generation, so perhaps I'd  
better start by looking at database integrity checks?

I'd be very happy to cooperate with Erwan or anyone on this.

As always great work

Cheers

Jim



--
Jim Stuttard
























--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws