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

Sorry Cimode, but this didnt go through...

On Oct 22, 11:33 am, Cimode <cim...@xxxxxxxxxxx> wrote:
On 22 oct, 18:42, dutone <dut...@xxxxxxxxxxx> 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", "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.

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 spread*** 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 spread*** 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 spread***'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 *** 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.


.