ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / форен кей на varchar поле вместо int??
21 сообщений из 21, страница 1 из 1
форен кей на varchar поле вместо int??
    #34324390
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Доброго дня.
Борюсь за веру 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:04
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324600
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
ДедушкаПрошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы. Далеко не всегда "хуже". Скажем так, это зависит от кол-ва строк, р-ра текстового поля и выполняемых к этой таблице запросов. Отаке.
...
Рейтинг: 0 / 0
12.02.2007, 16:53
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324638
Sk(A)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sk(A)
Участник
ДедушкаПрошу помощи в аргументации почему ключ по текстовым полям хуже связи через первичный ключ таблицы.
Спасибо.
- Скорость пересоздания индексов и размер индекса;
- Ивановых Иванов Иванычей может быть много...:);
- 3-ий принцип нормализации БД;
...
Рейтинг: 0 / 0
12.02.2007, 17:02
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324645
Sk(A)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sk(A)
Участник
Один1Далеко не всегда "хуже".
Таки почти всегда хуже...)
...
Рейтинг: 0 / 0
12.02.2007, 17:03
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324653
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
ДедушкаБорюсь за веру 8)

Ересь!!!

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

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

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

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

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

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

С теоретической же точки зрения, дополнительное поле идентификатора может показаться даже излишним. Если вас не убедило вышесказанное и не особо интересует производительность, то можете перейти в лагерь Joe Celco, назвать остальных id-иотами, и отказаться от введение такого поля.
...
Рейтинг: 0 / 0
12.02.2007, 17:28
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324782
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Sk(A)- 3-ий принцип нормализации БД;Вы, наверное, хотели сказать о 3-ей нормальной форме ? Если да, то хотелось бы услышать ее в Вашей интерпретации. А также - какое отношение она имеет к упомянутой в первом топике ситуации...
...
Рейтинг: 0 / 0
12.02.2007, 17:37
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324835
Sk(A)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sk(A)
Участник
ChA
Да Вы правы - НФ.
Не помню третья - ли, но одинаковые аттрибуты не должны дублироваться в разных таблицах, как в случае с
gr_name и person_name если исходить из того, что сущность у них одна...
...
Рейтинг: 0 / 0
12.02.2007, 17:49
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34324943
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Sk(A)Не помню третья - ли, но одинаковые аттрибуты не должны дублироваться в разных таблицах, как в случае с gr_name и person_name если исходить из того, что сущность у них одна...IMHO, Вам не мешало бы освежить свои знания по НФ, а также уточнить для себя, что обычно подразумевается под сущностью в РМД.
...
Рейтинг: 0 / 0
12.02.2007, 18:15
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34325003
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
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:38
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34325011
Профсоюз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Профсоюз
Участник
ДедушкаДоброго дня.
Борюсь за веру 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, 18:40
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34325095
Michael Vasilev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Michael Vasilev
Участник
Я вот чего не могу понять из описания.
Имя группы и имя персоны это одно и тоже? Какая связь между ними?
Персона может быть группой? Или группа может быть персоной?
Персона может входить в группу?
...
Рейтинг: 0 / 0
12.02.2007, 19:11
| Ответить | Цитировать | Написать  
форен кей на varchar поле вместо int??
    #34325281
Sk(A)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sk(A)
Участник
ChAIMHO, Вам не мешало бы освежить свои знания по НФ, а также уточнить для себя, что обычно подразумевается под сущностью в РМД.
При всем уважении :
Cлепо следовать канонам - IMXO не верный путь, иногда специально идеш на денормализацию БД, чаще из-за скорости или "так-сложилось"...)
ChAчто обычно подразумевается под сущностью в РМД
Не плодите "сущностей", без надобности...)
(c) Козьма Прутков

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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