Leximus пишет:

> Категория 1 имеет обозначение “pk”.
> Категория 2 имеет обозначение “fk”.
> Категория 3 имеет обозначение “pfk”.
> Категория 4 имеет обозначение “d”

Зачем бы это все городить ? В метаданных СУБД и так описано,
какое поле является PK, FK, PKFK или еще как.
Это тебе затруднит потом использование полей, будешь все
время тыркаться набирать ненужные "pk", "fk". К тому же
чел. который пишет запросы - зачем ему вообще знать,
PK оно или FK ? Какая разница ?

> • После обозначения категории в имени поля следует символ “_”.
> • Далее в зависимости от категории следует имя таблицы:
> Категория 1,3,4: следует имя таблицы, в котором находится поле

А rolename-ы ? Если ДВА таких поля в дочерней таблице будет ?

> Категория 2: следует имя таблицы, на которое ссылается ключ.
> • После имени таблицы, в имени поля следует символ “_”.
> • После чего следует непосредственно имя поля, обозначающее её значение.
> Пример:
> Категория 1: pk_tEmployees_Id
> Категория 2: fk_tEmployees_Id
> Категория 3: pfk_tEmployees_DBUIN
> Категория 4: d_tEmployees_Name

а в имя поля писать имя ее таблицы - вообще дебилизм IMHO.
Задолбаешься потом набирать, а в жизни это ничем не поможет.
Posted via ActualForum NNTP Server 1.4

belugin пишет:

> Я бы оставил:
> - Имя таблицы должно отображать данные хранящиеся в таблице.
> - Суммарное количество символов имени таблицы не должно превышать XX
> символов (минимальная из макимальных длин полей, поддерживаемых СУБД).
> - Имя таблицы должно состоять из латинских символов и/или цифр.
+1
Вот еще у нас таблицы большими буквами, поля - маленькими. Ничем
особенно тоже не помогает, просто так, красиво.
Posted via ActualForum NNTP Server 1.4

apapacy пишет:

> Желательно, чтобы в разных таблицах одна и та же сущность имела
> одинаковое имя (ИМХО-разумеется).

Ты наверное что-то не понимаешь в этой жизни. Сущность - это таблица.
Сущность представляется таблицей. Как она может быть "в разных таблицах" -
не понятно. Видимо имелось в виду "идентификатор сущности", т.е. первичный
ключ таблицы.

Тогда, если именовать поле
> суррогатного ключа ID во всех таблицах - требует именовать в связанных
> таблицах, как customer_ID/customerID. Меня это всегда сбивало. Поэтому
> для таблицы Customers я использую поле customer или customerId - и так
> во всех связанных таблицах.

Ну, это вполне разумно. Мы делаем так же.
Posted via ActualForum NNTP Server 1.4

Naf пишет:
> кстати вопрос, таблицы именовать в единственном числе али множественном?
Мы - в единственном делаем. Т.е. по названию экземпляра.
Posted via ActualForum NNTP Server 1.4

mcureenab пишет:
> Вообще, префиксы и прочие украшения меют второстепенный смысл, а
> префиксы предложенные автором практически не несут дополнительной
> информации (всё это есть в словаре БД). Гораздо важнее сосредоточиться
> на лингвистических аспектах задачи. Например, название таблицы должно
> быть существительным в едиственном/множественном числе.

Согласен абсолютно !

Название столбца
> не должно содержать его тип или дублировать название таблицы. Например в
> столбце "дата размещения заказа" таблицы "заказ", слово "дата" указывает
> на тип данных, а слово "заказа" повторяет название таблицы. И то и
> другое содержится в словаре БД. Поэтому название дожно быть изменено,
> например на "размещён", что в SQL запросе будет читаться как
> "заказ.размещён" - коротко, ясно и почти на естественном языке.

согласен частично, думаю тут могут быть иключения, потому что
-- в таблице может быть несколько атрибутов, связанных с "размещением",
например, вид размещения, дата размещения, время размещения, характер
размещения. В этом случае "дата" - название не типа данных, а атрибута
размещения, они просто в этом случае совпадают. (я бы кстати переименовал бы
лучше тип данных (домен), во что-то типа date_t)
-- иногда кроме слова "date" вообще в название атрибута нечего вставить.
Ну вот есть у нас таблица "событие" там есть поле "время". Его можно назвать
либо "время", либо "время события", и оба названия будут неверными по
предлагаемому соглашению. Можно конечно назвать его "произошло в", но, ей Богу,
просто "время" проще и понятнее.
-- Иногда мы даже на естественном языке говорим про какой-то атрибут что-то типа
"дата выдачи паспорта". Тогда и в БД лучше атрибут так и называть.
Причем "выдача паспорта" было бы неправильно, потому что выдача паспорта -
это процесс, явление, а "дата выдачи паспорта" - это его свойство уже.
"Выдан в" и коряво, и не звучит, и не понятно - дата или время.
Т.е. я хочу сказать - эти правила должны быть рекомендациями.
Posted via ActualForum NNTP Server 1.4

mcureenab пишет:

> Это только пример не претендующий на полноту. В паспорте этот атрибут

Ну я и дополнил :-)
Posted via ActualForum NNTP Server 1.4

Leximus пишет:
> А как вы считаете, префикс таблицы должен быть или нет?
Нет.

> Мне кажется что удобно былобы в запросе сразу видеть что и к какому типу
> относится!

Для этого есть алиасы таблиц, которые в запросах обязательно должны
и так использоваться для сложных запросов.

Ведь например если запрос из представления то его долго можно
> искать в списке таблиц в менеджере! А вы как считаете?

Чего его искать -то ? не понял нифига. У него есть имя, оно уникально,
взял да нашел.
Posted via ActualForum NNTP Server 1.4

Aviant пишет:

> вот поэтому у представлений и имеет смысл делать префикс.
> У таблиц - нет

Чем таблица от представления функционально отличается ?
Ничем. Так что и префиксов не надо.
Posted via ActualForum NNTP Server 1.4

mcureenab пишет:
> В Оракле есть представления словаря БД ALL_CATALOG, так что выяснить тип
> отношения не составляет труда.

Это есть практически во всех современных СУБД,

Однако, запросы к представлениям
> приходится делать с большой осторожностью, поскольку их эффективность
> может оказаться просто катастрофической.

Так не надо делать такие вьюхи просто.

> Вообще, довольно редко представленя БД удаётся использовать повторно,
> так что на счёт их названий можно особо не париться.

Если его нельзя использовать повторно, то на фиг оно вообще нужно ?

> В идеале представления и таблицы должны быть взаимозамеяемыми. С этой
> позиции различать их не есть хорошо, ведь рано или поздно отношение,
> которое было таблицей может стать представлением и наоборот, а украшения
> названий только внесёт путаницу.

Во, это -- правильная мысль.
Posted via ActualForum NNTP Server 1.4

mcureenab пишет:

> Например, для декомпозиции сложного SQL запроса на несколько простых,
> чтобы читаемость запроса улучшить, уменьшить объём сетевого трафика на
> передачу текста SQL запроса,

О, да я погляжу, вы достойные проблемы там решаете... Особенно актуальна
проблема сетевого траффика, создаваемого большими запросами.
Posted via ActualForum NNTP Server 1.4