Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Office Space - the Movie
Message
De
16/01/2004 13:42:59
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
15/01/2004 21:20:43
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00866562
Message ID:
00867590
Vues:
16
>Back when I worked for a certain branch of a certain state government (nearly 10 years ago), the debate even between the DBAs on whether to use surrogate keys or not was quite fervent. So if the so called professionals couldn't agree, I can't be too hard on the poor cat that was thrust into programming due to need and lack of an alternative. Although the flexibility of the tools can make it easy for a coder to get sloppy, I think a lot of the poor design decisions are a result of simple ignorance....you don't know what you don't know. How many programmers do you know that haven't even heard of, much less read Steve McConnell's Code Complete?? :)
>
>On normalization, I think it's critical to take the initial database design to, at least, third normal form, however, I'm not opposed to break form a small bit to accomodate tool and performance issues BUT (big but because jason got back!) only after reaching third normal form and documenting reasons why the regression was taken.
>
>Calculated fields are evil! :)

I have the one type of case where I have a sort-of calculated field, and that's the tables which are used to build treeviews. I've had a hierarchical organizational structure (divisions, subdivisions, subsubdivisions etc), which was loaded from an external text file into a table, and then it was recursively scanned to build the tree. I added one field which was the treeview key. Its sole purpose was to put the records into the order they needed to be to populate the treeview sequentially. The process got sped up by a factor of 30 (the slow part ran only when a new text file arrived, not each time a treeview was drawn).

Don't know if this counts as a calculated field, because it's not calculated within the record, but rather from the position of the record related to other records. It still needed to be repopulated each time the table changed, so in that sense it was a calculated field.

I've used this less than ten times in the last three years - and I still keep that one highlighted in my mind, because it's such a damn exception that needs special handling. I wish I had a simpler and more elegant solution.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform