Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Primary Keys, etc ...
Message
From
08/06/2001 16:54:28
 
 
To
08/06/2001 13:34:05
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00515653
Message ID:
00517228
Views:
19
>I'm not sure why you think having huge amounts of data would hurt this >concept. Could you explain ?

I was referring to not using codes at all. For example, suppose I had a file of expense categories with nothing except the description of the categories in it. Then when I entered the expenses ... I would select the category from that file and put the entire category description in the expenses file. That would mean that if someone wanted to change the description of the category then all of the category descriptions in the expenses file would have to be updated. Messy but seldom occurs.



>Hi Don,
>
>>>Maybe its best to forget this whole concept and revert to intelligent keys.
>>
>>I have been coming to the same conclusion. It seemed like a nice idea to begin with but as they say ... the devil is in the details. If you haven't already figured it out ... I like simple. At first it was simple ... but no longer.
>
>>>If you don't have/want a commercial framework, you should be writing your own >set of classes, tools and userinterfaces.
>>
>>Which is exactly what I am doing and is why I am searching for the best data structure on which to base my classes. Not using codes at all is as simple as it gets and I am surely attracted to that concept. However, that just seems to go against all my years of development instincts. On the other hand it seems tha only systems with huge amounts of data would be noticeably affected by this concept. I think I am going to try it.
>
>I'm not sure why you think having huge amounts of data would hurt this concept. Could you explain ? I would think that just when having to deal with huge amounts of data, one should minimize joins. And as noted, using surrogate keys in general increases the need of having joins.
>
>Sure, when using surrogate keys, you could use 32 bit integers which take less space as a foreign key oposed to the avarage intelligent key, but having as much as intelligent data in a table could save you headaches when having performance problems.
>
>As I said before. Intelligent keys and surrogate keys have different properties. Sometimes its better to use surrogates, sometimes you need to revert to intelligent.
>
>Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform