Jump to content

teka

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About teka

  • Rank
    member
  • Birthday 04/25/1957

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Michael- That may be a workable solution, it's just not a relational one. This means that adding additional parts requires additional code. Now, if you don't understand how to implement a fully relational solution, and based on your posts you may not, then it doesn't mean those are wrong. Your example unfortunately is not applicable to the earlier discussion because you are addressing a temporal component of the data. The last ten years has seen much work to understand these issues, and they result in a further normalization of the logical model into a Sixth Normal Form, which means
  2. This is an overly-complex structure, since you have what data modelers call two synonyms, that is two entities that appear similar. Fundamentally you are assuming Invoice vs Purchase order from a certain point of view. This can cause problems, especially when you wish to handle multiple points of view. Isn't a Purchase Order from the buyer equivalent to the seller's Invoice? Here is how this has been handled by others... Remain neutral on the point of view, and have an overriding Super-entity type, Contract, which may be of many types, request for quote, price contract, order, pu
  3. To Corn, Michael, David, DMontano et al... Often within the Party supertype table in SQL databases the attribute NameLegal applies to both subtypes. In the case of an organization subtype, this value is the full legal name, i.e. "Apple Computer, Incorporated", for an individual, it is also the full legal name, i.e. "Philo Thomas Farnsworth, III". For a group, it can be the full name of the group, i.e "Shipping Department". Like wise dateBirth and dateDeath, are also applicable to both subtypes, for an organization the incorporation or incception date, for a person the date of birth.
  4. It is one thing to have an enlightened discussion of issues where people are open-minded and try to learn, I am always willing to work toward this goal. One thing I will not do is engage in unproductive argument against arcane arbitrary departures from proven foundation knowledge, that based on many of the proposed ideas in this thread, have no proven basis other than anecdotal, and are so vociferous in their ignorance that they may also lack the ability to recognize that they in fact might be quite ignorant of the fundamentals. Now, there are two possible replies to someone question
  5. http://www.dbdebunk.com/page/page/3161496.htm
  6. Do you start from a blank file for every solution then? I truly believe that some level of practice must be absolute. You can't play high school ball against the Lakers, but I really think you need to go and be sure you know what normalization is. Seems from the context of your post that you don't. I hope that the client doesn't have to ask if the solution will break if they try to add an out of state customer...
  7. Well that may be normalization in some universe, just not this one...
  8. For more reading on data modeling and why it is anot as intuitive as folks suggest, see: http://www.dmreview.com/article_sub.cfm?articleId=1082215
  9. Pardon me, but it's not called de-normalization unless you fully normalize the model in the first place. Then it's simply called an arbitrary data model. If that is what is being argued then that's fine with me, you cannot then assert that everything is hunky-dorey and there will not be any issues. That is why normalization precedes de-normalization, so everyone can know fully the consequences of allowing anomalies and what will need to be done in scripts to compensate, check, and correct for them. But Codd, Fagin, and Date, et al proved mathematically that there WILL be anomalies.
  10. There may be more than one correct answer, but there are lots of incorrect solutions that the customer will end up paying for one way or another. I still have not heard any proven justification for abandoning using the Relational Model. That is what you are arguing for is it not? H.L Mencken said it better that I could in 1917: "There is always an easy solution to every human problem--neat, plausible, and wrong."
  11. Again logical vs physical... The attributes of the entity need not be stored in the table itself as a physical artifact. The reason for subtyping in the Logical Model is that different subtypes may have different unique attributes, as well as some common ones that are inherited through the SuperType. Soren quoted a link to Petrowski's site data-tagging-classification-vs-organization showing how in FM6 that a physical implementation of a subtype might have separate and variable numbers of attribute records, and thus no nulls. But FileMaker does not store nulls anyway, so what's the b
  12. Portals? I like to stick with Kachel's advice to almost never use the native FM portals for adding records since they are so weird. That seems like an arbitrary breakdown to me, why wouldn't phone and fax numbers be considered alike, as they all use the public switched telephone network, so it could be subtyped from the SuperType Contact Mechanism as PSTN Contact Mechanism. But there is no reason in the PHYSICAL FileMaker implementation that you couldn't implement this with separate table occurrences tied to the same table specifying a different subtype.
  13. Nothing personally, Ender, you usually have good points, but you're wrong on this...you make an assertion here but not really supported...This is a sore point for me as I always see FM Developers making "One table wonders", as in you wonder how it keeps data from getting corrupted, and you wonder why they are using a relational database. This is a fallacious argument, tying interface to data structure. There is nothing inherent about a relational structure REQUIRING a complex interface, but this is implied (false dilemma)...this indicates to me an all-too prevalent confusion of th
  14. Thanks Lee, yes theory would be the WRONG place. I guess the precise term would be Logical Data Model Discussions. Here are the additional diagrams for Postal Address Info and Party Contact Number.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.