Имена и элементы данных
От: Аноним Джо Селко  
Дата: 24.04.06 02:54
Оценка: 90 (3) -2
Статья:
Имена и элементы данных
Автор(ы): Джо Селко
Дата: 09.04.2006
Глава из книги “Стиль программирования Джо Селко на SQL”
Неудачные имена для элементов данных приводят к тому, что код бывает трудно, а то и невозможно прочитать.
Невозможность чтения — не шутка. В старину компании, разрабатывавшие программное обеспечение, нарочно искажали имена и удаляли из исходного кода форматирование, чтобы скрыть от покупателей алгоритм. Эта традиция все еще жива, хотя, может быть, изначальное намерение и утрачено. В августе 2004 г. в одной из групп новостей по SQL была опубликована программа, в которой все имена состояли из одной буквы и длинной цепочки цифр.
В настоящее время существуют стандарты метаданных ISO-11179, описывающие правила именования элементов данных и регистрации стандартов. Поскольку это стандарт ISO, его надлежит применять не только в SQL, но и вообще везде.
Стандартизация, немного печатного мастерства и некоторый здравый смысл — вот слагаемые успешной работы.


Авторы:
Джо Селко

Аннотация:
Глава из книги “Стиль программирования Джо Селко на SQL”
Re: Имена и элементы данных
От: Аноним  
Дата: 24.04.06 04:19
Оценка:
>Стремление новообращенных программистов SQL использовать IDENTITY, GUID, ROWID или другое нестандартное средство >автонумерации в качестве ключа проистекает из привычки работать с магнитными лентами. Им хочется знать, в каком порядке >строки добавлялись к БД, точно так же, как раньше им нужно было знать порядок добавления записей в конец магнитной >ленты!

При чем тут GUID какая есчо автонумерация,причем тут магнитные ленты?
IDENTITY, GUID, ROWID нестандартное средство ну ну
бред полный бред
Re: Имена и элементы данных
От: _FRED_ Черногория
Дата: 24.04.06 07:23
Оценка:
Здравствуйте, Джо Селко, Вы писали:

ДС>Статья:

ДС>Имена и элементы данных
Автор(ы): Джо Селко
Дата: 09.04.2006
Глава из книги “Стиль программирования Джо Селко на SQL”
Неудачные имена для элементов данных приводят к тому, что код бывает трудно, а то и невозможно прочитать.
Невозможность чтения — не шутка. В старину компании, разрабатывавшие программное обеспечение, нарочно искажали имена и удаляли из исходного кода форматирование, чтобы скрыть от покупателей алгоритм. Эта традиция все еще жива, хотя, может быть, изначальное намерение и утрачено. В августе 2004 г. в одной из групп новостей по SQL была опубликована программа, в которой все имена состояли из одной буквы и длинной цепочки цифр.
В настоящее время существуют стандарты метаданных ISO-11179, описывающие правила именования элементов данных и регистрации стандартов. Поскольку это стандарт ISO, его надлежит применять не только в SQL, но и вообще везде.
Стандартизация, немного печатного мастерства и некоторый здравый смысл — вот слагаемые успешной работы.


ДС>Авторы:

ДС>Джо Селко

ДС>Аннотация:

ДС>Глава из книги “Стиль программирования Джо Селко на SQL”

В магазине на Б. Сампсоньевском скоро будет?
Help will always be given at Hogwarts to those who ask for it.
Re: Имена и элементы данных
От: ctmike  
Дата: 24.04.06 19:29
Оценка:
Здравствуйте, Джо Селко, Вы писали:


CREATE TABLE Constant
(lock CHAR(1) DEFAULT 'X' NOT NULL PRIMARY KEY
 CHECK (lock = 'X'),
pi REAL DEFAULT 3.141592653 NOT NULL,
e REAL DEFAULT 2.718281828 NOT NULL,
phi REAL DEFAULT 1.618033988 NOT NULL,
..);
INSERT INTO Constants DEFAULT VALUES;


Я чегото в СКУЛЕ не знаю?? Или нижняя строка должна віглядеть как INSERT INTO Constant DEFAULT VALUES;
Re[2]: Имена и элементы данных
От: Аноним  
Дата: 25.04.06 08:04
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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

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

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

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

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