 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / October 2007Is it Possible to Enforce This Relationship at the DB Level?
DB layout is as follows: -------------------------------- | Client | -------------------------------- 1 | | 0..* ------------------------------- | Service | ------------------------------- 1 | | 1 --------------------------------- --------------------------- | Spreadsheet Config | 1 ------ 1..* | Cell Config | -------------------------------- --------------------------- 1 1 | | | | 1 | -------------------------------- | | Spec | | -------------------------------- | 1 | | | | | 1..* | -------------------------------- | | Field | 1----------------------------| -------------------------------- Every client has a spreadsheet that must implement a version of Spec. For this version, the cell config must corresponding to cells in the spreadsheet containing fields for the given Spec. As long a Cell Config references a Fileld, th DB will be happy, but the problem I have is making sure that the Fields referenced by Cell Config are indeed children of the Spec referenced by Spreadsheet Config. Is it possible to enforce this at a DB level? Maybe my model is flawed? Thanks > DB layout is as follows: > [quoted text clipped - 46 lines] > > Thanks In principle it is possible, assuming your DBMS supports something like SQL's CREATE ASSERTION statement for example.  SignatureDavid Portas On Oct 15, 2:00 pm, "David Portas" <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote: > > DB layout is as follows: > [quoted text clipped - 49 lines] > In principle it is possible, assuming your DBMS supports something like > SQL's CREATE ASSERTION statement for example. I'd like to enforce this based on the data model and its relationships. Although to me, it doesn't seem possible without an additional layer of logic. The need for a check assertion in a RDMS tells me that cerain cituations must be enforced at a higher level. This is one of them I guess. Thanks > I'd like to enforce this based on the data model and its > relationships. [quoted text clipped - 3 lines] > cituations must be enforced at a higher level. This is one of them I > guess. Maybe your definition of a data model differs from mine. All such constraints are surely part of that model irrespective of what syntax the DBMS uses. If you have some particular DBMS in mind then maybe someone will have other suggestions about features supported by that product. Perhaps a redesign would also be possible but I'm reluctant to begin a design-by- newsgroup exercise. -- David Portas > > I'd like to enforce this based on the data model and its > > relationships. [quoted text clipped - 12 lines] > redesign would also be possible but I'm reluctant to begin a design-by- > newsgroup exercise. Very good point. Design-by-newsgroup has almost always been based on flawed analysis. Second, "enforcing this based on the model" is clearly an implementation issue, not a modeling issue. > > > I'd like to enforce this based on the data model and its > > > relationships. [quoted text clipped - 18 lines] > Second, "enforcing this based on the model" is clearly an implementation > issue, not a modeling issue. How so? What I am trying to do is pin down the entities/relationships involved in a process and, given the "model" that I've come up with, it appeared that certain relationships would lead to the model's integrity being violated. Although I was not sure, and thought maybe my model was flawed. Maybe you believe it's a implementation issue because the "enforcement" (in my case I was looking for enforcement via referential integrity) actually takes place at the logical level, but this does not mean that you have to forgo the concept when creating a conceptual diagram. > > "David Portas" <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote in message > [quoted text clipped - 28 lines] > integrity being violated. Although I was not sure, and thought maybe > my model was flawed. It's not the model which is flawed, it's your knowledge of data fundamentals which orevents you from making a distincton between the logical and physical layers. My head hurts with the amount of gibberish and crappola you pour down in a single sentence. > Maybe you believe it's a implementation issue because the > "enforcement" (in my case I was looking for enforcement via > referential integrity) actually takes place at the logical level, but > this does not mean that you have to forgo the concept when creating a > conceptual diagram. There would be no doubt to somebody who has read at least ONE book about RM that this is an implementation issue as both David Portas and David Cressey already pointed out. Buit you obviously lack the intellectual onnesty to recognize it. > > > "David Portas" <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote in message > [quoted text clipped - 44 lines] > David Cressey already pointed out. Buit you obviously lack the > intellectual onnesty to recognize it. Blah, blah blah, Blah, blah blah, damn Cimode, I hope you charge by the hour cause you take up a whole bunch of time and talk a lot of sh.t, but at the end of the day, you provide nothing insightful or relevant to the root topic . Really, you manage to shift the topic. Hence, this reply. So, being the megalomaniac that you appear to be, I'm going to jump off this post's ship and let you get the last word. Lay back, maybe untuck your shirt and unclip you cellphone from your hip, and offer up a relevant closing post. [Snipped] > > > How so? What I am trying to do is pin down the entities/relationships > > > involved in a process and, given the "model" that I've come up with, [quoted text clipped - 23 lines] > relevant to the root topic . Really, you manage to shift the topic. > Hence, this reply. Check out *Idiocracy* by Mike Judges, you would get a lead role in it by the amount of crappola you pour down in a single minute. The so called *topic* you brough tup is nothing else than an attempt to get your job done by others. I do not believe it presents the slightest interest to anybody except for idiots like you. > So, being the megalomaniac that you appear to be, I'm going to jump > off this post's ship and let you get the last word. Lay back, maybe > untuck your shirt and unclip you cellphone from your hip, and offer up > a relevant closing post. Been called worse... It is difficult if not impossible, to deal coherently whith what's inherently incoherent. Just leave database management and go do something else more productive with you life. On Oct 16, 7:03 am, David Portas <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote: > > I'd like to enforce this based on the data model and its > > relationships. [quoted text clipped - 15 lines] > -- > David Portas I'm not trying to start a group design effort, but his original model certainly seems to me to have the Cell Config in the wrong place. At the logical lege, the connections should be described verbally (the cardinality can be there but blank connections between entities leaves too many unidentified assumptions. So many business systems designers unconsciously think everything about their application is "intuitively obvious" when the truth it, it is not obvious, sometimes not even to the initiated. Ed > On Oct 16, 7:03 am, David Portas > [quoted text clipped - 25 lines] > cardinality can be there but blank connections between entities leaves > too many unidentified assumptions. Wrong place, how so? The diagram got screwed up so let me clarify. The CLIENT can provides a SERVICE Each SERVICE is described by a SPREADSHEET The SPREADSHEET must conform to a SPEC A SPEC mandates that one supply values for its FIELDS A SPREADSHEET has many CELLS which correspond to to FIELDS of its chose SPEC > > On Oct 16, 7:03 am, David Portas > [quoted text clipped - 38 lines] > A SPREADSHEET has many CELLS which correspond to to FIELDS of its > chose SPEC So these are your conceptual rules...What an ignorant. You don't even know what a relation is. On Oct 16, 4:03 am, David Portas <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote: > > I'd like to enforce this based on the data model and its > > relationships. [quoted text clipped - 12 lines] > redesign would also be possible but I'm reluctant to begin a design-by- > newsgroup exercise. What I was trying to say is that not all constraints can be enforced via relationships, hence the need for a RDMS to allow one to create a high level constraint with statements like check assertion. My original question appears to fall into this category, since I cannot see away to guarantee that the Cell Config table will include only rows of the Field table that are children of the Spec table referenced by Spreadsheet Config. Although maybe something was wrong with my model, which is why I initially posted my question. Thanks > On Oct 16, 4:03 am, David Portas > > What I was trying to say is that not all constraints can be enforced > via relationships, hence the need for a RDMS to allow one to create a > high level constraint with statements like check assertion. I think you mean "not all constraints can be enforced by foreign keys alone". Am I right? I agree of course but you would be wrong to think that other types of constraint are not an equally legitimate part of conceptual and logical models. That's a mistake common to ER-modelling practice and it's a problem that ORM for example was specifically designed to correct. The problem being "I can't draw a picture of this relationship so it isn't part of my model!". You see why this is purely an implementation issue? A SQL CHECK or ASSERTION is not in principle at a "higher level" than a FOREIGN KEY constraint - it just looks that way because you don't like the syntax (actually, neither do I!). SignatureDavid Portas > My original question appears to fall into this category, since I > cannot see away to guarantee that the Cell Config table will include [quoted text clipped - 5 lines] > > Thanks On 19 oct, 21:58, "David Portas" <REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote: > > On Oct 16, 4:03 am, David Portas > [quoted text clipped - 27 lines] > > > Thanks David, I believe you will soon find out that dutone is a VI. Stop encouraging him into pouring more crap than he already poured down... >> In principle it is possible, assuming your DBMS supports something like >> SQL's CREATE ASSERTION statement for example. > > I'd like to enforce this based on the data model and its > relationships. Where you say data model I am sure you mean "logical model" or "conceptual model". Although most people would understand what you mean when you use that term, it is a colloquailism that can/will be misconstrued by readers of this newsgroup. More importantly, if you do take the advice you will get about reading books on fundamentals you will find it easier if you know those books use the term data model for something very different than you expect. > Although to me, it doesn't seem possible without an additional layer > of logic. > The need for a check assertion in a RDMS tells me that cerain > cituations must be enforced at a higher level. I suspect you might be thinking that referential integrity constraints should be enough to represent the business rules of your entire enterprise of interest. That is not possible even in principle. There are all kinds of other constraints that one needs, and SQL is supposed to implement some of them (e.g. the check constraints you refer to, and general constraints/assertions). Whether your SQL implementation provides them is another matter, but in any case SQL doesn't provide all the constraint mechanisms you could want, and if it does it may not support them flexibly enough (e.g. by allowing checking to be deferred). In practice you will have to enforce some assertions in your application, but only because your SQL server doesn't. You should take advantage of whatever limited constraint enforcement your SQL implementation provides, for a whole lot of reasons. Roy On Oct 17, 12:44 am, "Roy Hann" <specia...@processed.almost.meat> wrote: > >> In principle it is possible, assuming your DBMS supports something like > >> SQL's CREATE ASSERTION statement for example. [quoted text clipped - 31 lines] > > Roy Thanks for providing some decent feedback Roy. I understand that not all business rules can be enforced by a RDMS. When coming up with a conceptual and logical model, one has to decide how much influence they want to have the system based on the relationships, attributes, super/sub types, etc.. decided upon. In most situations one would want to alleviate the application from having to deal with referential integrity checks by constructing the appropriate relationships and letting the RDMS enforce them. Now, maybe the mention of "RDMS" will arouse the "those are implementation issues!" ilk, but I think that it should not prevent someone from considering them. Am I going to have some high priced schmuck create some diagrams in some pretty modeling notation with a bunch of lines and crows feet, and then tell him his design was too tied into the implementation because we're going to use Berkeley DB? At any rate, I'm getting off topic. My initial question was that my conceptual model was flawed, based on the inability to enforce the appropriate relationship at the logical level, and that I might be able to come up with a better design to achieve this. Though I couldn't see how, I thought I could be overlooking something. Thanks > On Oct 17, 12:44 am, "Roy Hann" <specia...@processed.almost.meat> > wrote: [quoted text clipped - 66 lines] > achieve this. Though I couldn't see how, I thought I could be > overlooking something. The only think you are overlooking is your abbysmal and the tons of crappola you pour down in a single minute. > Thanks > DB layout is as follows: > [quoted text clipped - 46 lines] > > Thanks In *no case* presentation should determine design. Proper design should be the consequence of studying sound principles of relational modeling. For more info... Introduction to Database Systems. CJ Date > > Is it possible to enforce this at a DB level? Maybe my model is > > flawed? > 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.... > > > Is it possible to enforce this at a DB level? Maybe my model is > > > flawed? [quoted text clipped - 5 lines] > 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. > > > > Is it possible to enforce this at a DB level? Maybe my model is > > > > flawed? [quoted text clipped - 10 lines] > 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. > > > > > Is it possible to enforce this at a DB level? Maybe my model is > > > > > flawed? [quoted text clipped - 18 lines] > 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. > > > > > > Is it possible to enforce this at a DB level? Maybe my model is > > > > > > flawed? [quoted text clipped - 26 lines] > > Is it me or is this a joke. You're a joke. 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'm automatically importing spreadsheet data sent from various clients, all of whom will be sending them in different formats. In the scope of my system, what way, other than the fact they are called "spreadsheets", are they being used as a presentation element? Should I cajole the clients to export their spreadsheets to CSV,XML, or maybe YAML to avoid using a presentation element? 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. > > > > > > In *no case* presentation should determine design. Proper design > > > > > > should be the consequence of studying sound principles of relational [quoted text clipped - 11 lines] > > > 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. [quoted text clipped - 10 lines] > > 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. > 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. 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 truth is you simply have no clue what you are doing and hope that somebody will do it for you without getting paid. > 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. > 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? > 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. > 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 f.ck yourself. Sorry Cimode, but this didnt go through... > > > > > > > In *no case* presentation should determine design. Proper design > > > > > > > should be the consequence of studying sound principles of relational [quoted text clipped - 30 lines] > 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 a.s 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? [quoted text clipped - 3 lines] > 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 [quoted text clipped - 7 lines] > If you plan on being insulting to people who simply try to help, then > you can go f.ck 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. [Snipped] > > > > 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 [quoted text clipped - 15 lines] > is irrelevant to my initial post, and serves only to stroke your > socially distraught and/or inept personality. So now I am the one *confused*. After several people here pointed out to you that you were confused. As for my personality, I havce been called worse... > Spreadsheets are presentation "concepts", sure I agree. But in my > situation, they are being used as nonuniform data sources and cannot > be dismissed. Speaking of changing your mind... So now you agree that spreadsheet are indeed presentation concepts after you maintained the opposite on the previous sentence (quote: who's speaking about presentation)...As I said you lack the intellectual honnesty to recognize your errors. > > > 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. It is not a design issue you are facing but an implementation issue moron!!!....Both David Portas and David Cressey have already pointed out that to you but it seems you head is burried into so much crappola that you simply can't make a sense of simple words obvious to everybodyu except you... > > 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... [Snipped gibberish] My conclusion is based solely on the posts you have made and the ignorance and incoherence you have made and that several people already pointed out to you. [Snipped gibberish] > > The truth is you simply have no clue what you are doing > > Not true. That's a fact not a question... [Snipped Gibberish] > > > 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! What is a *datasource* anyway? I am not sure such word even exists in the dictionnary... Do you have any clue what presentation is? You keep using terms you redefine continuously as you choose to ignore their established meaning. I come to the conclusion as you are simply making up more and more gibberish as you advance instead of recognizing simply that the usual crappola you pour down on people does not *work here*...But what else could be expected from a VI. [Snipped Gibberish] > > Humm, maybe a datasource! > What is a *datasource* anyway? I am not sure such word even exists in > the dictionnary... It's been in my working vocabulary for about 20 years. Don't ask for a definition. As the Satchmo said, "if you have to ask, then you'll never know." While some of my comments might seem to support your position, I am in no way contemptuous as you are towards soemone who has a problem to solve and is looking for handles on the solution. >>>Humm, maybe a datasource! >> [quoted text clipped - 8 lines] > way contemptuous as you are towards soemone who has a problem to solve and > is looking for handles on the solution. It's the antonym of "datasink". > > > Humm, maybe a datasource! > > What is a *datasource* anyway? I am not sure such word even exists in [quoted text clipped - 3 lines] > definition. As the Satchmo said, "if you have to ask, then you'll never > know." I would not dare to ask a definition when the chance to get one is close to zero. This is comp.database.theory ...The original poster should try comp.databases.working.crappola > While some of my comments might seem to support your position, I am in no > way contemptuous as you are towards soemone who has a problem to solve and > is looking for handles on the solution. It's not about being contemptuous but about setting things straight and treating a spade as a spade ougth to be treated. When intellectual honnesty is absent there is nothing left but exposing or being sarcastic...Because I am not everyday in a good mood, I choose exposing... > Sorry Cimode, but this didnt go through... > [quoted text clipped - 146 lines] > 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. > > > > > > > In *no case* presentation should determine design. Proper design > > > > > > > should be the consequence of studying sound principles of relational [quoted text clipped - 30 lines] > 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 a.s 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? [quoted text clipped - 3 lines] > 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 [quoted text clipped - 7 lines] > If you plan on being insulting to people who simply try to help, then > you can go f.ck 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. >>>>>>>>In *no case* presentation should determine design. Proper design >>>>>>>>should be the consequence of studying sound principles of relational [quoted text clipped - 144 lines] > helped me? The only one I have insulted is you. In no way have you > tried to help anything but your own weak arguments. Whatever happened to "So, being the megalomaniac that you appear to be, I'm going to jump off this post's ship and let you get the last word. Lay back, maybe untuck your shirt and unclip you cellphone from your hip, and offer up a relevant closing post." Come on, man, you promised us! Pony up! |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.