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_at_news.aliant.net>
>
> 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.
>
>
>
> Well you dolt, initially it was about design, until you chimed in.
>
>
>
> 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.
>
>
>
> Not true.
>
>
>
> No you sot, thats your hope.
>
>
>
> 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.
>
>
>
>
> Humm, maybe a datasource!
>
>
>
> 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.
>
>
>
> 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.
| Client |
| Service |
| Field |
Date: Wed, 24 Oct 2007 10:57:22 -0300
Message-ID: <471f4f4a$0$14862$9a566e8b_at_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 - 15:57:22 CEST