Re[2]: Имена и элементы данных
От: Аноним  
Дата: 25.04.06 08:04
Оценка:
Здравствуйте, Аноним, Вы писали:

>>Стремление новообращенных программистов SQL использовать IDENTITY, GUID, ROWID или другое нестандартное средство >автонумерации в качестве ключа проистекает из привычки работать с магнитными лентами. Им хочется знать, в каком порядке >строки добавлялись к БД, точно так же, как раньше им нужно было знать порядок добавления записей в конец магнитной >ленты!


А>При чем тут GUID какая есчо автонумерация,причем тут магнитные ленты?

А>IDENTITY, GUID, ROWID нестандартное средство ну ну
А>бред полный бред

Просто человек ни с чем кроме сиквела не работал. Он не понимает, что походу геморрно тягать через параметры составной ключ, когда _гораздо_ удобнее передавать один единственный идентити.
Но понять его можно. И мне бы он возразил, что ключевой колонкой должна быть только одна на 4 уровне оптимизации, и то, что индексацию лучше делать по колонке, несущей смысловую нагрузку, а не содержащую последовательность чисел... В се это понятно.
Но вот как-то исторически сложилось так, что пока 99%там без идентити никуда )))

А вообще будет любопытно попробовать поконструировать базы без идентити.
Но вот от "OrderID foreign key reference" или там "FK__" я пожалуй низачто не откажусь!

Да он просто не понимает, что иногда индексы и удаляются, и не всегда с использованием визуальных манагеров. А часто с консоли. Если у меня имена индексов сконструированы по четким правилам, то мне никуда смотреть больше не нужно. В конце концов! Индекс — это скорее даже не логическая, а физическая если уж на то пошло сущность. А значит к констрейнтам его рассуждения не применимы. Цвет(Размер...) — это логика. Уникальность — это физика.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.