Another word for "Phone Number"?

[teka]

http://www.dbdebunk.com/page/page/3161496.htm

[Genx]

I'm confused...

Are you claiming to be the enlightened intellectual and that we are the ignorant morons who refuse to listen to reason?

And for how long must it be proven so again and again

Apparently you have never studied law.. or even formally debated. For you to be right and us to be ignorant you first have to rebut our arguments with reasoned explanations as opposed to telling us that we're wrong and dismissing us for our apparent extreme lack of intelligence.

No one here as far as i can tell is arguing against normalization as a concept. They are arguing against the need for enterprise level normalization that deals with terrabytes of data in a small business's organization who's data in most cases won't surpass a GB in it's useful life span.

What you seem to be arguing however is that there is one structure concept that is applicable to all problems and I put it to you that if this were the case our jobs wouldn't exist. A client could just plug and play 1 or 2 appropriate modules and that would be it.

If the topic is of such interest to you (and this is a serious question) why don't you get a job in normalization consulting at an enterprise level?

[Ender]

Alright, lighten up folks! It's only relational design theory.

teka,

You had asked about these sort of design choices some time ago:

http://fmforums.com/forum/showtopic.php?tid/185942/

but it seems now that you’re hearing some opinions, you don’t like what you hear. Hey, we’re just trying to suggest a practical limitation to normalization. Give us a break! :

Anyway, earlier you made some assertions and posed some questions about my position, so I’ll try to oblige.

Nothing personally, Ender, you usually have good points, but you're wrong on this...

What, me wrong? Say it ain’t so!

you make an assertion here but not really supported...This is a sore point for me as I always see 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.

Yeah, I know what you mean about unsupported assertions. I hate those too. My only excuse is being pretty busy today. I guess I thought it was clear enough given the abstractness of your examples. But it looks like comment and Genx have filled in about this, so I’ll reserve further comments unless you have a specific structure you wish to discuss.

As for “One table wonders”, I hope you give me more credit than to think I’d recommend or use a flat structure. C’mon, man! I’ve been weaving relationship webs for years. Check my post history if you don’t believe me.

Anyway, what’s this business about corruption? A database doesn’t get corrupt just because it’s flat. On the contrary, in a normalized system, there are more keys and cascading delete things to watch out for (not corruption, but it might appear so to the user if these are out of place).

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).

Hey watch what you’re calling fallacious! : Maybe you like to spend a lot of effort trying to hide tangled innards in a pretty skin, but some of us don’t like to dink around with all that. While the interface need not depend on the model, it sure makes it easier to go with it than to fight it.

..this indicates to me an all-too prevalent confusion of the Logical versus Physical model.

Although I’m trying to talk about the ERD here (not the relationship graph), it’s reasonable to consider the implications of the ERD in what the relationship graph will look like. I don’t find this confusing.

Consider a solution with Salespeople, Invoices, and Contacts. In the "normalized" world, you might consider the Salespeople and Contact to both be sub-classes of People, and therefore design a model that shows this, but unless you intend to build the database with only one People table, this is not a useful abstraction. I personally don’t like the idea of overloading tables with different entity-roles, so I wouldn’t build a solution this way, nor would I build the ERD to show it that way. I’d keep them as separate entities.

Simpler design? Normalized to what level? 1NF? 2NF? 3NF? Which relations would you denormalize? For what purpose? And what would the possible data corruption issues become then?

Well, if we’re talking about the Address example, I like Fenton’s idea for a general purpose Contact database, where phone numbers and addresses come up in different places for different purposes, but I can’t generalize that for every situation.

In one place you may only need to record someone’s home address, in another case it may be important to have a dedicated shipping address and a dedicated billing address, or as in a Contact database, it may be important to have flexibility and allow a variety or address types.

I know what you’re thinking. “Ender must have flipped his lid!” or “He must not be as smart as he thinks he is,” or maybe something offensive. :

So why would they not reside in a single entity? For simplicity. You may tell me that the same address could be a Contact’s home address and could be an Invoice’s Ship To address or Bill To address and could be an Employee’s home address, and if that’s your situation, then a single Contact with related Address may work best. But I don’t think that’s typical. More likely, the only address needed for an employee is a single home address (and possibly an emergency contact). Similarly, the scope of a Contact database may be restricted to a different subset of people (maybe totally independent of the Invoice’s contacts). For example, the people in an executive’s Contact database may not have anything to do with the peons that actually buy widgets from the company on a daily basis.

Sure the scopes of these could be limited by filtering the relationships, but in my view there’s not really an advantage to doing so, over using local fields or separate related tables. I don’t mind having a table for Contact addresses, and then keeping the Employee’s address as a set of fields. This may grate against the normalized view of the universe, but it simplifies the implementation and gives some reassurance about security (no chance of the executive’s friends getting sent an Employee Termination letter because of some script mishap).

Don’t get me wrong, if there’s some useful purpose to having things combined, then it’s worth doing. I’d see this for example, if letters need to be sent from a combined list of different groups of people.

I still don’t get the “Corruption” argument, but I think others have already addressed the rest.

If you can clarify without getting your undies in a bunch, I'd appreciate it. :

[Ender]

[spoilerq:1] Le mieux est l'ennemi du bien.[/spoilerq]

[spoilera:1]The original quote in French is "Le mieux est l'ennemi du bien.", from Voltaire's Dictionnaire Philosophique (1764) Literally translated as "The best is the enemy of good.", but is more commonly cited as "The perfect is the enemy of the good."

In other words, pursuing the "best" solution may end up doing less actual good than accepting a solution that, while not perfect, is effective. One could also infer that the best makes that which is good seem to be worth less than it is.[/spoilera]

Aaack! Has Soren brainwashed you, Stephen?? STEP AWAY FROM THE LIGHT...COME BACK TO US, STEPHEN.... :shocked:

[Genx]

LOLOLOL!!

[LaRetta]

:jester:

Although ... I doubt Stephen could be brainwashed.

[Ender]

http://www.dbdebunk.com/page/page/3161496.htm

Hey teka, what's with the reply?

If you've got a myth to debunk, let's hear it (use small words for us uneducated folk). But don't go calling David J. "vociferous". What's up with that?

[AudioFreak]

Interesting thread for such a simple question.

Teka,

If you just wanted to dismiss peoples ideas and thoughts, why participate in the thread?

Michael

Edited June 6, 2007 by Guest

[teka]

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 questioning the basis of your work, one can either attack them, as in "Who the hell are you to question us, and how many doctoral degrees do you have, etc..." or one may engage in some introspection to determine if their knowledge might indeed be deficient. If such a person were to ask me where they might review their knowledge of the fundamentals of data management I would be only too happy to oblige with a reference list.

[AudioFreak]

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.

It's comments such as the above that turn a simple discusion into an "unproductive argument".

Just my 2 cents from what I read.

[Ocean West]

:backtotopic: