Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Можно ли создавать словари состоящие из одного поля типа varchar или всетаки должно быть также числовое поле id с уникальным значением? В моем случае есть таблица Анкета трудоустраиваемого, и таблица профессий трудоустраиваемого(связь один ко многим). Список возможных профессий хранится в словаре. Мне кажется если записывать профессию как varchar а не ее id поиск и выборки будут проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 07:31 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Храни с ID, меньше проблем будет, например, с каскадами. К тому же длина индексируемого поля ограничена. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 07:41 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Вообще не понимаю, как могут быть справочные таблицы без ID. Как ссылочную целостность стороить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 08:25 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Предлагаю тему перенести в проектирование. -- Dik76 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 08:33 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
arniВообще не понимаю, как могут быть справочные таблицы без ID. Как ссылочную целостность стороить?Так у него и не будет никакой нахрен ссылочной целостности. Впору сказать "РТФМ нормализация". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 08:45 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
YurmanМожно ли создавать словари состоящие из одного поля типа varchar или всетаки должно быть также числовое поле id с уникальным значением? В моем случае есть таблица Анкета трудоустраиваемого, и таблица профессий трудоустраиваемого(связь один ко многим). Список возможных профессий хранится в словаре. Мне кажется если записывать профессию как varchar а не ее id поиск и выборки будут проще. Вот напринимает оператор кучу анкет, а затем вдруг заметит, что в твоем словаре вместо "Проктолог" написано "Практолог". И придется ему, бедному, все анкеты открывать и в каждой ашипку исправлять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 09:24 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
ЛентяйИ придется ему, бедному, все анкеты открывать и в каждой ашипку исправлять.Нееее... зачем... Он собирается делать Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 09:27 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Лентяй Л> Вот напринимает оператор кучу анкет, а затем вдруг заметит, что в твоем Л> словаре вместо "Проктолог" написано "Практолог". И придется ему, Л> бедному, все анкеты открывать и в каждой ашипку исправлять. Разве в этом дело? Вопрос о том, что лучше использовать: натуральные или искусcтвенные ключи постоянно обсуждается... В данном случае использование наименования в качестве первичного ключа не целесообразно из-за необходимости создания каскадных обновлений, что вызывает массовые апдейты.. А для FB есть еще и ограничение на размерность индекса. 2автар Выборки от наличия искусственного ключа усложняются не на много, а в более сложных случаях, чем у тебя наоборот облегчают жизнь (имею ввиду выбор м\у состовным первичным ключом или искусственным). Вопрос ты имхо задаешь из-за отсутствия знаний sql, поэтому советую начать с его изучения. -- Dik76 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 09:43 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам ЛентяйИ придется ему, бедному, все анкеты открывать и в каждой ашипку исправлять.Нееее... зачем... Он собирается делать Код: plaintext Я постарался объяснить разницу между двумя подходами. А как бороться с созданными собой же трудностями - это уже другая тема... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 10:21 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Dik76 Разве в этом дело? Вопрос о том, что лучше использовать: натуральные или искусcтвенные ключи постоянно обсуждается... В данном случае использование наименования в качестве первичного ключа не целесообразно из-за необходимости создания каскадных обновлений, что вызывает массовые апдейты.. А для FB есть еще и ограничение на размерность индекса. Чего-то ты не о том... Имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 10:25 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Лентяй Л> Чего-то ты не о том... Имхо. Список возможных профессий хранится в словаре. Мне кажется если записывать профессию как varchar а не ее id поиск и выборки будут проще. Из этого я понял, что у автора имеется справочник профессий, но он не хочет сажать из него id, а хочет сажать name, т.е. воспользоваться им как PK. Может я конечно и не прав... -- Dik76 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 11:15 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
не целесообразно из-за необходимости создания каскадных обновлений тю. а о дублировании значений такого естественного ПК в столбце FK ты подумал? Тут до каскадной прокто-логии даже не доходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 11:15 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
kdv k> не целесообразно из-за необходимости создания каскадных k> обновлений k> k> тю. а о дублировании значений такого естественного ПК в столбце FK ты k> подумал? Тут до каскадной прокто-логии даже не доходит. Вот я и хочу донести до автора все минусы. -- Dik76 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 11:22 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
Можно. Но в Вашем случае непрактично. Классификация, плюсы, минусы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 15:05 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
YurmanМожно ли создавать словари состоящие из одного поля типа varchar или всетаки должно быть также числовое поле id с уникальным значением? В моем случае есть таблица Анкета трудоустраиваемого, и таблица профессий трудоустраиваемого(связь один ко многим). Список возможных профессий хранится в словаре. Мне кажется если записывать профессию как varchar а не ее id поиск и выборки будут проще.Судя по задаче, это будет относительно небольшая БД, с относительно низкой интенчивностью использования. Поэтому можете не бояться ни лишнего объема, ни каскадных апдейтов. Смело делайте ваш справочник без суррогатного PK. Получите тот плюс, что запросы попроще будут (на один JOIN поменьше). Другой вопрос, если б вы тряслись над объемом или если бы у вас была нужда в репликации между серверами, тогда однозначо -- суррогатный PK. А каскадные апдейты для справочников мало страшны, справочники по своему определению содержат очень редко меняемую информацию. Один раз в пятилетку поправят "практолог" на "проктолог" и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 15:07 |
|
||
|
Создание словарей
|
|||
|---|---|---|---|
|
#18+
mir Один раз в пятилетку поправят "практолог" на "проктолог" и все.Не уверен. Знаю, что больницы держат специальных медицинских статистиков, которых сверху заваливают всевозможными формами и изменениями не меньше бухгалтеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 15:33 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33345357&tid=1545594]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
125ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 407ms |

| 0 / 0 |
