Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Index on multiple integer fields
Message
De
21/12/2005 09:05:39
Mike Yearwood
Toronto, Ontario, Canada
 
 
À
20/12/2005 11:07:04
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows 2000 SP4
Database:
Visual FoxPro
Divers
Thread ID:
01079271
Message ID:
01079840
Vues:
30
Normally you're correct. However, efficiency can be part of the scenario. Limited to mathematics "correct" refers to the desired result. However, a math teacher will still mark a student's work incorrect if they get the right result while employing the wrong (suboptimal) technique.

Define the desired result and you have to adjust your meaning of correct. Why else are there 4 variations of the definition of correct in the dictionary? One of which is:

4) To adjust so as to meet a required standard or condition: correct the wheel alignment on a car.

If the wheel alignment is out, the car will still move, but inefficiently. It is only considered corrected when the inefficiency is removed.

>Correct and efficient are not the same thing. Correct gets you the desired result. Efficient gets you the correct result faster, with fewer resources, or both.
>
>>Hi Craig
>>
>>I often feel that correct has to mean the best possible choice and so efficiency enters into it. As Fabio pointed out, if you travel from Utah heading East, when you meant to go West, it might be the correct way if, you wanted to pick up someone/something to the East before going West. If that is not your scenario, then going East first is clearly incorrect.
>>
>>If you were hammering nails and missing most of the time and bending many nails, you may be getting the job done, but no one would say you're doing it correctly.
>>
>>In fact, option a below CANNOT be correct! It's missing "FOR UPPER(LastName+FirstName) =".
>>
>>I'd say option c would be the correct way to find one particular name. The clarification of the request - do they want one name, are they looking for duplicates will refine the scenario so I could choose the correct option.
>>
>>If they want a list of all customers with that name, I'd probably argue for an option e
>>
>>lcFullName = UPPER(m.LastName + m.FirstName)
>>SELECT * FROM Customers WHERE UPPER(LastName + FirstName) = m.lcFullName
>>
>>If, like Terry Thurber, I wanted to populate a listbox I might choose option f
>>
>>SET ORDER TO TAG FullName
>>m.lcFullName = UPPER(m.LastName + m.FirstName)
>>SEEK m.lcFullName
>>DO WHILE UPPER(LastName + FirstName) = m.lcFullName
>> AddItem blah, blah
>> SKIP
>>ENDDO
>>
>>Correctness depends on the scenario.
>>
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform