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

From: Bob Badour <>
Date: Wed, 24 Oct 2007 10:57:22 -0300
Message-ID: <471f4f4a$0$14862$>

dutone wrote:
> Sorry Cimode, but this didnt go through...
> On Oct 22, 11:33 am, Cimode <> wrote:

>>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
>>>>>>>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
>>>>>>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.


> No, your confused. Your lame dismissive quip about presentation *not*
> determining design
> is irrelevant to my initial post, and serves only to stroke your
> socially distraught and/or inept personality.
> Spreadsheets are presentation "concepts", sure I agree. But in my
> situation, they are being used as nonuniform data sources and cannot
> be dismissed.
>>>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.

> Well you dolt, initially it was about design, until you chimed in.
>> chosen design is one that has no 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

> The problem (read, your problem) in regards to my post is that you
> justify your conclusions based on inapplicable facts and false
> assumptions. Those, you dolt, are truly signs of an ignorant lazy git
> - you nitwit!
> I'm looking for a cookbook solution huh, yeah sure. Another
> inapplicable fact used to justify your conclusion. If your dumb ass
> took the time to read my post and look at tables and relationships
> [insert Cimode's nonsensical rant about using the proper terminology
> regarding the terms "table" and "relationship"] you'd see that their
> is no solution and that the problem can only be solved with a higher
> level check. (Now initially I wasn't a 100% sure of this, but no one
> has proven otherwise and this was how the post concluded; well, the
> relevant part).
> My boss... bwahhahah.
>>The truth is you simply have no clue what you are doing

> Not true.
>>and hope that somebody will do it for you without getting paid.

> No you sot, thats your hope.
>>>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.

> Wow you fool, you answered a question...
> It's too bad that no one asked "what attributes are required to
> represent a spreadsheet's cells in a database table".
> Have you been so formally educated that you adhere to the Jepordy
> style of conversation?
> Unfortunately -for you, of course- your "answer" furthers my belief
> that it is /only your hope/ that somebody will do my work for me
> without getting paid. And your shameless attempt to prove your weak,
> fact less argument, only furthers this conclusion.
> I mean come on, you haven't substantiate any of your arguments, and
> all your lame attempts to do so only substantiate everything I'm
> saying Now().
> Ok, wait, wait... the only thing you're somewhat on track with is my
> ability to throw around terms that, technically speaking, could have
> been used in the improper context.
> But only a techie lame such as yourself would get caught up in this
> when it is quite clear what my question is.
>>>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?

> Humm, maybe a datasource!
>>>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.

> Please, don't act like you're offering some sort of insight by
> answering a nonsensical rhetorical question. You are so pathetic,
> whew, it just keeps getting better: you deride my initial post's
> content, yet respond to something that's not only mentioned for
> satirical purposes, but off topic for this newsgroup. Come on, you
> seem like someone who would be so quick to run your mouth about off
> topic posters and newsgroup FAQs.
>>>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.

> Try to help; you really are a dickhead. Who did I insult that has
> helped me? The only one I have insulted is you. In no way have you
> tried to help anything but your own weak arguments.

Assuming the cardinalities you posted are correct, a single relation suffices to describe Service, Spreadsheet Config and Spec, and a single relation suffices to describe Cell Config and Field. One can safely use the join of any 1:1 relations in place of the separate relations.

| Client |
       | 1
       | 0..*

| Service |
       | 1
       | 1..*

| Field |

This simpler design obviates your original problem. Received on Wed Oct 24 2007 - 15:57:22 CEST

Original text of this message