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

On Oct 21, 1:45 pm, Cimode <cim...@xxxxxxxxxxx> wrote:
On 19 oct, 19:21, dutone <dut...@xxxxxxxxxxx> wrote:



On Oct 16, 12:59 pm, TroyK <cs_tr...@xxxxxxxx> wrote:

On Oct 15, 3:54 pm, dutone <dut...@xxxxxxxxxxx> 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", "spread***", "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 spread*** 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.








.

Quantcast