×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
unless there is a specific reason to use a PRIMARY key, which I
believe is the only key you can add to a table....correct?
Why would you not want a PK? While I believe you can do a FK relation on
a unique index, generally speaking they're on the PK. I can't imagine
any reason you'd want to define a table that didn't have a unique
primary key. If there's not one in the business domain add a surrogate
key (personally I'd use them all the time, but that's a different
discussion)
If you're doing all your IO via SQL don't let the programmers dictate
indexes either, that's the domain of a DBA. Now, programmers tend to be
intelligent, and they're free to _recommend_ a new index, but their SQL
will work w/out any indexes (just not quickly) so they never _need_ an
index. This is especially true if they want an index because they want
the data in a given order. An index on lastname may be of no use even if
the order by is lastname. SQL may decide it's faster to just sort the
result set.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
midrange.com
