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

On Oct 21, 1:45 pm, Cimode <cim..._at_hotmail.com> wrote:
> On 19 oct, 19:21, dutone <dut..._at_hotmail.com> wrote:
>
>
>
> > On Oct 16, 12:59 pm, TroyK <cs_tr..._at_juno.com> wrote:
>
> > > On Oct 15, 3:54 pm, dutone <dut..._at_hotmail.com> wrote:
>
> > > > > > Is it possible to enforce this at a DB level? Maybe my model is
> > > > > > flawed?
> > > > > 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 straight...you 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.

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'm automatically importing spreadsheet data sent from various clients, all of whom will be sending them in different formats. In the scope of my system, what way, other than the fact they are called "spreadsheets", are they being used as a presentation element? Should I cajole the clients to export their spreadsheets to CSV,XML, or maybe YAML to avoid using a presentation element?

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. Received on Mon Oct 22 2007 - 18:42:16 CEST