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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 24 Oct 2007 10:57:22 -0300
Message-ID: <471f4f4a$0$14862$9a566e8b@news.aliant.net>

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

>>On 22 oct, 18:42, dutone <dut..._at_hotmail.com> 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 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.
>>
>>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
>>boss...

>
> 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 - 08:57:22 CDT