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

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. Received on Wed Oct 24 2007 - 18:44:02 CEST