Re: Is it Possible to Enforce This Relationship at the DB Level?

From: Cimode <>
Date: Mon, 22 Oct 2007 11:33:32 -0700
Message-ID: <>

On 22 oct, 18:42, dutone <> wrote:

> > > > > > In *no case* presentation should determine design. Proper design
> > > > > > should be the consequence of studying sound principles of relational
> > > > > > modeling.
> > > > > Huh, who said anything about presentation? I'm trying to construct an
> > > > > appropriate data model based on a set of business rules.
> > > > > Thanks for the advice....
> > > > "client", "spreadsheet", "cells", etc. all sound like user interface
> > > > or
> > > > presentation concepts. Difficult to tell without working definitions
> > > > for these entities that you have identified, though.
> > > Yes, words can imply a specific idea to someone at first; context,
> > > context, context.

> > > In my case, spreadsheets are what drives the whole process and must be
> > > decomposed before additional processes can take place.
> > > The associated tables the represent configuration information each
> > > client's service has.
> > Ok let me get this are basically saying to people here
> > that you want to design a system which purpose would be building a
> > data store where propositions would be presentation elements and then
> > your pretend that it has nothing to do with a confusion between
> > presentation and data layer.
> > Is it me or is this a joke.
> You're a joke.
Looking at the epidermic way you react to something so obvious makes a clear cut case of your ignorance and confusion. Both TroyK and I have tried to point out an obvious confusion but you keep arguing for some obscure reasons meaningful only to you. Case closed.

> Why don't you quit deferring to the notion of spreadsheets being a
> presentation element and look at the problem for what it is?
I doubt the problem here is truly about design or even spreadsheets.

The problem is that, as any ignorant and lazy git who find himself in position to have to design a db system with no formal education about relational modeling, you simply rely on the some magical hope to find an online cookbook approach that would help you look good with your boss...

The truth is you simply have no clue what you are doing and hope that somebody will do it for you without getting paid.

> I'm automatically importing spreadsheet data sent from various
> clients, all of whom will be sending them in different formats.
You do not need anything else than a name an X and a Y and a content represent spreadsheet information which obviously is not sufficient to qualify data a being structured and therefore ready to be structured.

> In the scope of my system, what way, other than the fact they are called
> "spreadsheets", are they being used as a presentation element?
What else could they be?

> Should I cajole the clients to export their spreadsheets to CSV,XML, or
> maybe YAML to avoid using a presentation element?

If you are convinced that it is simpler to export data into some format, send it and reparsing it back into a database instead of directly interfacing directly with their original data source that simply show how hopeless is your enterprise to build a decent system.

> Where should one store vital configuration information related to key
> entities then? Based on your stunning analysis, should I conclude that
> using a database to store configuration information is wrong? Oh, I
> hope someone tells all the CMS DB designers that they've been mixing
> presentation and data layers.
If they are as self assured and vociferous about their ignorance as you are, I have *no* doubt they did.

If you plan on being insulting to people who simply try to help, then you can go fuck yourself. Received on Mon Oct 22 2007 - 20:33:32 CEST

Original text of this message