Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / форен кей на varchar поле вместо int?? / 21 сообщений из 21, страница 1 из 1
12.02.2007, 16:04
    #34324390
Дедушка
Дедушка
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Доброго дня.
Борюсь за веру 8)
Код: plaintext
1.
Есть табл1(gr_code int identity( 1 , 1 ), gr_name varchar( 100 )) справочник групп. gr_code первичный ключ.
и табл2(pers_code int identity( 1 , 1 ), person_name varchar( 100 )) реестр пользователей. pers_code первичный ключ.
каждому пользователю сопоставляется группа (название группы gr_name совпадает с именем пользователя person_name).
Такая вот схема досталась в наследство 8(
Пытаюсь озвучить предложение ввести в табл2 поле gr_code и построить на нём форен кей на табл1
создатели этой схемы начинают меня чморить со словами: "есть же совпадение по gr_name и person_name... вот и джоинь таблицы по этим полям... а если уж так хочется создай ключ на этих полях..."
Прошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы.
Спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 16:53
    #34324600
Один1
Один1
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаПрошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы. Далеко не всегда "хуже". Скажем так, это зависит от кол-ва строк, р-ра текстового поля и выполняемых к этой таблице запросов. Отаке.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:02
    #34324638
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаПрошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы.
Спасибо.
- Скорость пересоздания индексов и размер индекса;
- Ивановых Иванов Иванычей может быть много...:);
- 3-ий принцип нормализации БД;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:03
    #34324645
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Один1Далеко не всегда "хуже".
Таки почти всегда хуже...)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:06
    #34324653
mcureenab
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаБорюсь за веру 8)

Ересь!!!

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

Использовать числа вместо строк выгоднее только потому, что строки обычно длиннее, занимают больше места в структурах БД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:14
    #34324681
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаБорюсь за веру 8)
mcureenab
Ересь!!!

HolyWars на пустом месте...

join'ить таблицы по ФИО еще большая ересь...)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:28
    #34324744
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаБорюсь за веруВремя крестовых походов в прошлом.
ДедушкаПрошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы.Путаница в понятиях. Первичный ключ может быть не только целым числом, но и строкой, и даже комбинацией полей.

По сути, на сравнение целых чисел уходит практически один такт процессора. Сравнение текстовых полей, особенно длинных может занимать гораздо больше процессорного времени. На малых объемах данных это может быть не критично. При больших, может сыграть роль даже объем пространства на HDD, будет больше обращений к самому медленному звену. А с учетом того, что первичный ключ мигрирует в подчиненные таблицы, то объем таких таблиц может многократно возрасти, если делать ключ длиннее минимально необходимого.

А если вдруг поменяется значение текстового поля, выбранного в качестве первичного ключа ? Для естественных ключей, которыми обычно и являются текстовые поля, это нередкое явление. Не верьте, если вам будут говорить "никогда". Как следствие, это может привести к обновлению большей части БД, что само по себе не очень хорошо, так как может сильно нагрузить сервер со всеми вытекающими, в том числе, "разбухание" транзакционных логов и способствовать дефрагментации таблиц из-за расщепления страниц данных. Значения суррогатных ключей никогда не меняются, если только вы не начнете развлекаться уплотнением последовательности значений путем заполнения "дырок", чем обычно занимаются начинающие разработчики БД или люди, которые неверно выбрали свою профессию.

С теоретической же точки зрения, дополнительное поле идентификатора может показаться даже излишним. Если вас не убедило вышесказанное и не особо интересует производительность, то можете перейти в лагерь Joe Celco, назвать остальных id-иотами, и отказаться от введение такого поля.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:37
    #34324782
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A)- 3-ий принцип нормализации БД;Вы, наверное, хотели сказать о 3-ей нормальной форме ? Если да, то хотелось бы услышать ее в Вашей интерпретации. А также - какое отношение она имеет к упомянутой в первом топике ситуации...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 17:49
    #34324835
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ChA
Да Вы правы - НФ.
Не помню третья - ли, но одинаковые аттрибуты не должны дублироваться в разных таблицах, как в случае с
gr_name и person_name если исходить из того, что сущность у них одна...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 18:15
    #34324943
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A)Не помню третья - ли, но одинаковые аттрибуты не должны дублироваться в разных таблицах, как в случае с gr_name и person_name если исходить из того, что сущность у них одна...IMHO, Вам не мешало бы освежить свои знания по НФ, а также уточнить для себя, что обычно подразумевается под сущностью в РМД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 18:38
    #34325003
mcureenab
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A) ДедушкаБорюсь за веру 8)
mcureenab
Ересь!!!

HolyWars на пустом месте...

Это шутка.

Sk(A)join'ить таблицы по ФИО еще большая ересь...)

join'ить таблицы по ФИО никак не противоречит реляционным принципым, более того это в духе реляционных БД. Чтобы не поднимать волну, оговорюсь, что чисто реляционные БД, ИМХО, уже давно не применяются. Введение суррогатных ключей и ссылок в духе объектных БД, своего рода переходный период в объектные БД на реляционном движке.

В исходной задаче на поле gr_name можно (и скорее всего нужно) определить уникальный ключ.

Для поля person_name можно определить ограничение ссылочной целостности gr_name. Что соответствует правилу "каждому пользователю сопоставляется группа (название группы gr_name совпадает с именем пользователя person_name)."

Если следовать этому правилу, придётся определить следующую модель

табл1(gr_code int identity(1,1), gr_name varchar(100))
табл2(pers_code int identity(1,1), person_name unique references табл1)

иначе проверить правило "название группы gr_name совпадает с именем пользователя person_name" только декларативными средствами будет проблематично.

Но возникает вопрос, сколько времени это правило будет оставаться в силе? Переименование группы или персоны становится нетривиальной задачей.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 18:40
    #34325011
Профсоюз
Профсоюз
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ДедушкаДоброго дня.
Борюсь за веру 8)
Код: plaintext
1.
Есть табл1(gr_code int identity( 1 , 1 ), gr_name varchar( 100 )) справочник групп. gr_code первичный ключ.
и табл2(pers_code int identity( 1 , 1 ), person_name varchar( 100 )) реестр пользователей. pers_code первичный ключ.
каждому пользователю сопоставляется группа (название группы gr_name совпадает с именем пользователя person_name).
Такая вот схема досталась в наследство 8(
Пытаюсь озвучить предложение ввести в табл2 поле gr_code и построить на нём форен кей на табл1
создатели этой схемы начинают меня чморить со словами: "есть же совпадение по gr_name и person_name... вот и джоинь таблицы по этим полям... а если уж так хочется создай ключ на этих полях..."
Прошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы.
Спасибо.

1. Если Ваша фраза "каждому пользователю сопоставляется группа" не просто так высказана, то необходимо обеспечивать ссылочную целостность. Из приведенного кода не видно, как она обеспечивается. Допускаю мысль, что Вы просто этого не указали. Поэтому для
начала предположу, что FOREIGN KEY все-таки имеется. Но тогда это будет, скорее всего так:



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE [табл1]
(
 [gr_code] int IDENTITY( 1 ,  1 ) NOT NULL
 , [gr_name] varchar( 100 ) NOT NULL
 , CONSTRAINT [PK_табл1] PRIMARY KEY ([gr_code])
 , CONSTRAINT [UQ_табл1_gr_name] UNIQUE ([gr_name])
 , CONSTRAINT [CK_табл1_gr_name] CHECK (LTRIM([gr_name]) <> '')
)
GO

CREATE TABLE [табл2]
(
 [pers_code] int identity( 1 , 1 ) NOT NULL
 , [person_name] varchar( 100 ) NOT NULL
 , CONSTRAINT [PK_табл2] PRIMARY KEY ([pers_code])
 , CONSTRAINT [UQ_табл2_person_name] UNIQUE ([person_name])
 , CONSTRAINT [FK_табл1_табл2] FOREIGN KEY ([person_name]) REFERENCES [табл1] ([gr_name])
)
GO

Вы же предлагаете следущий вариант:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE [табл1]
(
 [gr_code] int IDENTITY( 1 ,  1 ) NOT NULL
 , [gr_name] varchar( 100 ) NOT NULL
 , CONSTRAINT [PK_табл1] PRIMARY KEY ([gr_code])
 , CONSTRAINT [UQ_табл1_gr_name] UNIQUE ([gr_name])
 , CONSTRAINT [CK_табл1_gr_name] CHECK (LTRIM([gr_name]) <> '')
)
GO

CREATE TABLE [табл2]
(
 [pers_code] int identity( 1 ,  1 ) NOT NULL
 , [gr_code] int NOT NULL
 , CONSTRAINT [PK_табл2] PRIMARY KEY ([pers_code])
 , CONSTRAINT [UQ_табл2_person_name] UNIQUE ([gr_code])
 , CONSTRAINT [FK_табл1_табл2] FOREIGN KEY ([gr_code]) REFERENCES [табл1] ([gr_code])
)
GO

На мой взгляд, очевидно, что два четырехбайтовых поля (int) , легче чем два поля переменной длины, имеющих в пределе 100 байт (varchar(100)). Это первый аргумент. Аргумент второй: в случае необходимости внести изменения в справочник, приложение или
триггер должны обеспечить изменение записей в табл2, ссылающихся на изменяемую запись в табл1. если этого где-то не предусмотреть, то результат будет очевиден. Однако даже если все предусмотрено, то это все-таки два UPDATE вместо одного.

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

Третий вариан: целостность обеспечивается приложением. Хуже этого может быть только ситуация, когда целостность не обеспечивается вовсе.

И, наконец, самый худший целостность необеспечивается.

Вот нехитрый расклад. Предложите своим оппонентам поразмыслить на этим.

Впрочем, поскольку у меня нет всей исходной информации, то я могу ошибаться. В этом случае, расскажите ог своей ситуации поподробнее!


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 19:11
    #34325095
Michael Vasilev
Michael Vasilev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Я вот чего не могу понять из описания.
Имя группы и имя персоны это одно и тоже? Какая связь между ними?
Персона может быть группой? Или группа может быть персоной?
Персона может входить в группу?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 20:24
    #34325281
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ChAIMHO, Вам не мешало бы освежить свои знания по НФ, а также уточнить для себя, что обычно подразумевается под сущностью в РМД.
При всем уважении :
Cлепо следовать канонам - IMXO не верный путь, иногда специально идеш на денормализацию БД, чаще из-за скорости или "так-сложилось"...)
ChAчто обычно подразумевается под сущностью в РМД
Не плодите "сущностей", без надобности...)
(c) Козьма Прутков

Что считать сущностью-то...)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 20:52
    #34325341
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
mcureenab
Это шутка.

Я понял...)
mcureenab
join'ить таблицы по ФИО никак не противоречит реляционным принципым, более того это в духе реляционных БД.

Я сейчас, не говорю, о конкретных СУБД, но теория и "жисть" штуки разные...
mcureenab
Но возникает вопрос, сколько времени это правило будет оставаться в силе? Переименование группы или персоны становится нетривиальной задачей.
"Подпешусь" под-ентим - ибо иногда проще "плюнуть" и оставить как есть...)
Но, автор, просил доводы...)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2007, 21:51
    #34325439
mcureenab
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A)Что считать сущностью-то...)

Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в (ER) модели.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2007, 00:12
    #34325564
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A)Cлепо следовать канонам - IMXO не верный путь, иногда специально идеш на денормализацию БД, чаще из-за скорости или "так-сложилось"...)Путаемся в показаниях или пытаемся запутать ? Сначала вещаем про "3-ий принцип нормализации БД", который, судя по контексту, нарушается. Потом выясняется, что это не только не он, а, вообще, неизвестный науке зверь, да еще и в более чем неожиданных терминах и вольной интерпретации понятий. А теперь, еще и это ? Для того, чтобы осуждать каноны, как Вы выражаетесь, их следовало бы знать хотя бы в первом приближении, а не кидаться громкими фразами.
Sk(A)Что считать сущностью-то...)Если нет книг под рукой, может используете Google ? Заодно и про нормальные формы почитаете.

P.S. Может хватит фантазировать на вольную тему ? Становится уже неловко, чесслово.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2007, 00:39
    #34325587
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
mcureenabчисто реляционные БД, ИМХО, уже давно не применяются.Чисто реляционные - это какие ?
mcureenabВведение суррогатных ключей и ссылок в духе объектных БД, своего рода переходный период в объектные БД на реляционном движке.Реляционные БД "сожрут" объектную модель и не подавятся. А суррогатные ключи, сами по себе, не имеют никакого отношения к объектным БД. Они предназначены для решения сугубо практических целей, также как и индексы, о которых также нет никакого упоминания в РМД. В логической модели данных таковые ключи должны вообще отсутствовать, так как обычно не имеют никакого смысла в терминах предметной области. Если же, как-будто бы имеют, типа инвентарного номера, то они перестают быть суррогатными, а становятся естественными. Со всеми же вытекающими, как-то, стер один номер, написал другой, не исключено, что при этом ошибся, и вуаля, у нас уже 2 стула под номером 23.

P.S. Сразу согласитесь или пофлеймим ? ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2007, 09:25
    #34325889
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
ChAСначала вещаем про "3-ий принцип нормализации БД", который, судя по контексту, нарушается. Потом выясняется, что это не только не он, а, вообще, неизвестный науке зверь, да еще и в более чем неожиданных терминах и вольной интерпретации понятий.

В вольной, интерпритации - да, но именно "3-ий принцип нормализации БД" (такое определение допустимо, хоть и не совсем корректно...)

Википедия
Третья нормальная форма (3NF) — одна из возможных форм таблицы реляционной базы данных.

Таблица находится в третьей нормальной форме (3NF), если
она находится во второй нормальной форме (2NF),
и при этом любой ее не-ключевой атрибут зависит только от первичного ключа (Primary key, PK) или проще говоря, один факт хранится в одном месте .
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2007, 09:51
    #34325961
proposed amendment
proposed amendment
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
Sk(A) ChAСначала вещаем про "3-ий принцип нормализации БД", который, судя по контексту, нарушается. Потом выясняется, что это не только не он, а, вообще, неизвестный науке зверь, да еще и в более чем неожиданных терминах и вольной интерпретации понятий.

В вольной, интерпритации - да, но именно "3-ий принцип нормализации БД" (такое определение допустимо, хоть и не совсем корректно...)

Википедия
Третья нормальная форма (3NF) — одна из возможных форм таблицы реляционной базы данных.

Таблица находится в третьей нормальной форме (3NF), если
она находится во второй нормальной форме (2NF),
и при этом любой ее не-ключевой атрибут зависит только от первичного ключа (Primary key, PK) или проще говоря, один факт хранится в одном месте .


цитировать фундоментальные термины и понятия из викопедии - это крайне неудачная идея (даже не говоря о том, что приведенная цитата никак не поясняет вашего ляпа с "3-м принципом нормализации")

перестаньте смешить людей, все все и так давно поняли - еще один великий теоретик от РМД
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2007, 10:21
    #34326074
Sk(A)
Sk(A)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
форен кей на varchar поле вместо int??
proposed amendmentляпа с "3-м принципом нормализации")
Ляп мой - был, и когда на него, мне справедливо указали - я согласился с Cha.
proposed amendmentеще один великий теоретик от РМД
Ну право-же, бросьте...)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / форен кей на varchar поле вместо int?? / 21 сообщений из 21, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 500ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1544736]:
 0ms
get settings:
 11ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 162ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 49ms
get tp. blocked users:
 1ms
others: 243ms
total:  500ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]