Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.07.23;
Скачать: CL | DM;

Вниз

Название полей внешних ключей.   Найти похожие ветки 

 
SHD_   (2006-05-18 17:28) [0]

Хотелось бы узнать мнения специалистов как называть лучше внешние ключи так же как и в главной талице или по разному?
Например Case средстава типа ERWIN называют их одинаково, но лично мне проще составлять запросы когда они всё же разные.

CREATE TABLE T1(
 ID_T1 INTEGER NOT NULL,
 MyData1 INTEGER );
ALTER TABLE T1 ADD PRIMARY KEY (ID_T1);

CREATE TABLE T2(
 ID_T2 INTEGER NOT NULL,
 FC_T1  INTEGER NOT NULL,
 MyData2 INTEGER );
ALTER TABLE T2 ADD PRIMARY KEY (ID_T2);
ALTER TABLE T2 ADD CONSTRAINT FK_T1_T2 FOREIGN KEY (FC_T1) REFERENCES T1(ID_T1) ON DELETE CASCADE ON UPDATE CASCADE;

Так вот есть ли смысл назвать поле FC_T1 именем ID_T1?
И кстати если поля MyData1 и MyData2 будут называться одинаково какие могут быть трудности кроме того что в запросах придётся обращаться к ним через имена таблиц?


 
MsGuns ©   (2006-05-18 17:41) [1]

Я называю тем же, ибо это есть одна и та же сущность
Если при этом в именах полей есть префикс имени таблицы, то запросы к нескольким таблицам читаются значительно легче.


 
Ega23 ©   (2006-05-18 17:41) [2]

Я предпочитаю одинаковые названия. Но, конечно, не такие, как ID_T1 и ID_T2


 
MsGuns ©   (2006-05-18 17:51) [3]

>Ega23 ©   (18.05.06 17:41) [2]
>Я предпочитаю одинаковые названия. Но, конечно, не такие, как ID_T1 и ID_T2

Вот-вот, особенно на базах с сотней таблиц и ссылками на одни и те же объекты из десятков разных таблиц.

Можно комплимент ?
Мне нечасто доводилось встречать столь не по возрасту грамотных разработчиков БД. Если не секрет, откуда "дровишки" ? Учителя попадались грамотные ?
 ;)


 
Ega23 ©   (2006-05-18 17:55) [4]


> Учителя попадались грамотные ?


Угу. Мой знаменитый шеф.  :о)


 
Desdechado ©   (2006-05-18 18:23) [5]

я использую одинаковые говорящие названия в мастер и подчиненной таблице
это удобно, особенно когда таблиц море и связей в них тоже
можно четко отследить, что не перепутал сущность при обращении к ключу

единственное исключение, когда я добавляю буквы или цифры, - это наличие в одной таблице 2 и более ссылок на другую таблицу
тогда будет что-то вроде objfrom_id, objto_id или objupper_id, objlower_id

и солидарен с MsGuns ©   (18.05.06 17:41) [1] и Ega23 ©   (18.05.06 17:41) [2]


 
Третий   (2006-05-18 22:00) [6]

Если при этом в именах полей есть префикс имени таблицы

Я предпочитаю перфиксы, например, если

в первой таблице
tp1_ID, tp1_MyData

то во второй будет
tp2_ID, tp2_tp1_ID, tp2_MyData


 
Третий   (2006-05-18 23:33) [7]

MsGuns ©   (18.05.06 17:41) [1]
Я называю тем же, ибо это есть одна и та же сущность

Я бы не назвал это одной и той же сущностью.

Во второй таблице - всего лишь ссылка на некую сущность.


 
MsGuns ©   (2006-05-19 09:16) [8]

>Третий   (18.05.06 23:33) [7]
>Я бы не назвал это одной и той же сущностью.
>Во второй таблице - всего лишь ссылка на некую сущность.

Ссылка не есть что-то самостоятельное. Если она присутствует в таблице, то это значит, что хранящиеся в таблице сущности связаны с сущностями, на которые ссылаются.


 
ANB ©   (2006-05-19 09:30) [9]

Примерно так принято именовать поля и таблицы в нашей конторе


create table Common$Contractors
(
 Contractor_ID       integer                   not null,
 Contractor_Type_ID  integer                   not null,
 Contractor_Name     varchar2(80 byte)         not null,
 constraint Common$Contractors_PK primary key (Contractor_ID)
);
/
create table Mail$Boxes
(
 Box_ID    integer not null,
 Mail_Account varchar2(2000),
 Mail_Pass    varchar2(2000),
 Server_SMTP  varchar2(2000),
 Server_POP3  varchar2(2000)
 constraint Mail$Boxes_PK primary key (Box_ID)
);
/
create table Mail$Correspondents
(
 Correspondent_ID integer not null,
 Contractor_ID    integer not null,
 Mail_Addr varchar2(2000),
 constraint Mail$Correspondents_PK primary key (Correspondent_ID),
 constraint Mail$Correspondents_Contractors_FK foreign key (Contractor_ID) REFERENCES Common$Contractors(Contractor_ID)
);
/



Если мне нужно сделать несколько ссылок из одной таблицы на другую, я обычно добавляю окончание.

Например :

Contractor_ID_Sender
Contractor_ID_Recipient


 
Sergey13 ©   (2006-05-19 09:38) [10]

А БД абсолютно по барабану - как называть поля.
ИМХО, главное, что бы самому (и коллегам, если они есть) было понятно.


 
ANB ©   (2006-05-19 09:59) [11]


> ИМХО, главное, что бы самому (и коллегам, если они есть)
> было понятно.

БД то почти по барабану (есть свои ограничения), но вот понятность - вещь великая. А посему очень желательно иметь в конторе некий стандарт на именования и жестко ему следовать.

А то работал я с одной БД : 2000 таблиц с именами FN101, FN210, FN212  и полями в ней N1, N2, N15, D1. Правда там тоже было жесткое правило - во всех таблицах одинаковые поля одинаково назывались, что сильно помогло в работе.


 
SHD_   (2006-05-19 10:06) [12]

Вернёмся к моему примеру:

CREATE TABLE T2(
ID_T2 INTEGER NOT NULL,
FC_T1  INTEGER NOT NULL,
MyData2 INTEGER );
ALTER TABLE T2 ADD PRIMARY KEY (ID_T2);
ALTER TABLE T2 ADD CONSTRAINT FK_T1_T2 FOREIGN KEY (FC_T1) REFERENCES T1(ID_T1) ON DELETE CASCADE ON UPDATE CASCADE;

В какой то степени челу сразу понятно что FC поле внешнего ключа, а ID это это уникальный номер таблицы, далее название таблиц через (_). а вот если поля будут оба начинаться на ID то возникает небольшая путаница.


 
Val ©   (2006-05-19 10:07) [13]

Contractors.Contractor_ID - некая тафтология - не так ли?


 
Sergey13 ©   (2006-05-19 10:09) [14]

>В какой то степени челу сразу понятно что FC
FK было бы понятнее. 8-)


 
SHD_   (2006-05-19 10:19) [15]


> Sergey13 ©   (19.05.06 10:09) [14]


согласен ступил маленько
CREATE TABLE T2(
ID_T2 INTEGER NOT NULL,
FK_T1  INTEGER NOT NULL,
MyData2 INTEGER );
ALTER TABLE T2 ADD PRIMARY KEY (ID_T2);
ALTER TABLE T2 ADD CONSTRAINT FK_T1_T2 FOREIGN KEY (FK_T1) REFERENCES T1(ID_T1) ON DELETE CASCADE ON UPDATE CASCADE;

кстати было бы логичнее уникальные ключи с PK начинать. :)


 
Sergey13 ©   (2006-05-19 10:29) [16]

2[15] SHD_   (19.05.06 10:19)
> кстати было бы логичнее уникальные ключи с PK начинать. :)
Не совсем. Не все уникальные ключи - PK. Не все UK и PK состоят из одного поля. Бывают UK и PK из естественных ключей, и мне, например, хочется понимать, что в поле лежит - паспорт или ИНН. Насчет FK - в таблице может быть несколько полей ссылающихся на один справочник - мне так-же было бы удобнее понимать что в каком поле лежит.
Фигня все это. Я остаюсь при своем мнении [10].


 
SHD_   (2006-05-19 10:53) [17]


> Sergey13 ©   (19.05.06 10:29) [16]


Согласен с тобой почти во всём.

А есть где нить стандарты какие нить или советы там ГОСТы или ещё чё нить на название полей, таблиц и всего подобного?
Или только на уровне организации?


 
ANB ©   (2006-05-19 11:05) [18]


> Val ©   (19.05.06 10:07) [13]
> Contractors.Contractor_ID - некая тафтология - не так ли?
>

Я вообще то предпочитаю ID так и называть ID - но моему начальнику так больше нравится. Иногда удобнее ID вынести вперед. Но это уже дело привычки.

Однозначно вызовет путаницу FK_


 
ЮЮ ©   (2006-05-19 11:08) [19]

>ANB ©   (19.05.06 09:30) [9]

В нашей конторе это было бы так:

create table Contractors                          <- таблица в которй хранятся
                                                               <- сущности Contractor
(
ID       integer                    not null,
Typу   integer                   not null,
Name     varchar2(80 byte)         not null,
constraint Contractors_PK primary key (ID)
);

create table MailCorrespondents
(
ID integer not null,
Contractor    integer not null,                         <- имя сущности
Addr varchar2(2000),
constraint MailCorrespondents_PK primary key (ID),
constraint MailCorrespondents_Contractor_FK foreign key (Contractor) REFERENCES Contractors(ID)
);


 
Desdechado ©   (2006-05-19 11:18) [20]

а у меня обычно так
CREATE TABLE CLASSTYPES (
   TYPE_ID    INTEGER NOT NULL,
   TYPE_NAME  FULL_NAME /* FULL_NAME = VARCHAR(30) NOT NULL */,
   CLASS_ID   INTEGER DEFAULT 1 NOT NULL,
   REGION_ID  INTEGER NOT NULL
);
ALTER TABLE CLASSTYPES ADD CONSTRAINT PK_CLASSTYPES PRIMARY KEY (TYPE_ID);
ALTER TABLE CLASSTYPES ADD CONSTRAINT UQ_CLASSTYPES UNIQUE (TYPE_NAME, CLASS_ID, REGION_ID);
ALTER TABLE CLASSTYPES ADD CONSTRAINT FK_CLASSTYPES_CLASSES FOREIGN KEY (CLASS_ID) REFERENCES CLASSES (CLASS_ID);
ALTER TABLE CLASSTYPES ADD CONSTRAINT FK_CLASSTYPES_REGIONS FOREIGN KEY (REGION_ID) REFERENCES REGIONS (REGION_ID);


PS inline constraints ненавижу
PPS ID - очень часто зарезервированной слово, да и информации от него ноль, особенно если оно есть в каждой второй таблице


 
Val ©   (2006-05-19 12:09) [21]

>[20] Desdechado ©   (19.05.06 11:18)
что такое inline constraints ? объявление ограничений при описании полей? после описания полей до конца команды create table?
всвязи с чем ненависть, если не секрет?
где ID зарезервированное слово?
если оно будет в каждой первой(почти :)) - будет унификация

p.s. вообще, конечно, спор без смысла, пользы от ветки - разве что, новички посмотрят варианты :)



Страницы: 1 вся ветка

Текущий архив: 2006.07.23;
Скачать: CL | DM;

Наверх




Память: 0.53 MB
Время: 0.029 c
3-1148245972
lamer_y
2006-05-22 01:12
2006.07.23
Access


15-1151218322
Nic
2006-06-25 10:52
2006.07.23
Какие преимущества даёт компонент TActionList?


2-1151640162
delphiman2006
2006-06-30 08:02
2006.07.23
Непонятки по книге


5-1135866647
olegz77
2005-12-29 17:30
2006.07.23
Компонент - панель


4-1144642984
Vad
2006-04-10 08:23
2006.07.23
Меню чужого приложения