powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли делать отдельное поле для PK?
25 сообщений из 96, страница 3 из 4
Стоит ли делать отдельное поле для PK?
    #39605015
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wlr-lКот Матроскинпропущено...

Но почему-то Вы этого не сделали (как можно заметить, Ваш собеседник тоже усомнился в адекватности именно этого вопроса именно ему). Т.е. вопрос не просто бредов сам по себе, но и в контекст дискуссии попадает не очень.

Исходный вопрос "Стоит ли делать отдельное поле для PK?".

hVostt, Cane Cat Fisher и я сказали, что нет, не надо.

У тех, кто говорит, что надо, я и спросил "Как обеспечить уникальность пар USR_ID и USR_GROUP_ID, если есть ключ по ID?".
Еще раз, Вы потеряли нить беседы.

1. Вы спросили это не у "тех, кто говорит, что надо", а у hVostt (это к вопросу о нити беседы).
2. Вы-таки действительно не знаете ответа на этот вопрос?
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605030
Wlr-l
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кот Матроскин,
"2. Вы-таки действительно не знаете ответа на этот вопрос?"

Повторюсь.
Вопрос (не мой, а ТС): "Стоит ли делать отдельное поле для PK?". Это для отношения М:М, если Вы не помните первоначальную задачу.

Я (если Вы не прочли этот мой ответ): "Итак, у нас два потенциальных ключа: (USR_ID, USR_GROUP_ID) и (ID). Первый решает задачу уникальности пар USR_ID и USR_GROUP_ID. Второй эту задачу не решает."

Есть и другие способы обеспечения этой уникальности, например, найти внимательного оператора, который прежде чем начнет вводить данные, удостоверится, что ЭТОГО пользователя в Этой группе нет.

Конечно, можно мне задавать вопросы, но лучше ответить на вопрос ТС.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605039
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRosСвязь - всегда сама по себе.

Проблема вот в этом утверждении. Как только связь становится «сама по себе» и создаётся на какой-нибудь отдельной вкладочке «Связи» — это колхоз и выливается 100% в систему, которую с какой стороны не тронь, всё пойдёт по п.....е.

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

А то ты так свяжешь агрегат автомобиля с категорией холодильников, и всё выглядит здорово, только у пришедшего аналитика возникают вопросы, где взять канистру с бензином, чтобы всё нахрен сжечь и посадить на кол колхозников-разработчиков.

Связь не характеристика объекта.
Это объект, который связывает объекты.

Ты тут можешь все что угодно нафантазировать, но пока не поймешь что такое связь - ты не разработчик.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605048
Wlr-l
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ViPRos,

"Связь не характеристика объекта." Согласен!
"Это объект, который связывает объекты." Значит можно связывать связи!

Я тоже не понял Вашей мысли. Можно на простом примере заказа и позиции объяснить нам связь между этими объектами?
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605053
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, учитывая второй раз повторенный довод про оператора - похоже-таки не знаете.
А на вопрос ТС-а ответил давным-давно Cane Cat Fisher, исчерпывающе.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605056
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wlr-lViPRos,
"Это объект, который связывает объекты." Значит можно связывать связи!

Фундаментальный вопрос.
Интерпретация не всегда очевидна.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605057
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ошибка кроется в небрежном определение - объект.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605101
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wlr-lУ тех, кто говорит, что надо, я и спросил "Как обеспечить уникальность пар USR_ID и USR_GROUP_ID, если есть ключ по ID?"
PK + уникальный индекс из 2 полей, в чем проблема?
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605240
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosСвязь не характеристика объекта.
Это объект, который связывает объекты.

именно про это я и говорю. когда не получается описать отношения объектов в рамках самих объектов, выделяются вот такие костыли и суррогаты. это просто банальная неспособность спроектировать систему описания и определения объектов.


ViPRosТы тут можешь все что угодно нафантазировать, но пока не поймешь что такое связь - ты не разработчик.

мне не надо фантазировать, у меня есть готовая и внедрённая реализация, убедительно доказывающая, что отдельно выделенные связи как костыли -- это нафиг не нужная лишняя концепция-костыль.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605314
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
у меня есть готовая и внедрённая реализация, убедительно доказывающая....Она в одном экземпляре и навечно замкнута на 1-2-3 разработчиков. И ее почти никто не видел. :)

"уровня Галактики" это какбе лол... На экселях при желании/умении тоже можно вести учет "уровня Галактики" (многие так и делают). Т.е. пока этот тезис ниачомъ... :)

зы: Да, можно удалять гланды через ж*пу. Но успешность такой операции никак не доказывает, что именно так всегда следует делать.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605328
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Юзер 01Вопрос: если ли смысл для добавления отдельного ID для таблички USR_IN_GROUP? Или просто наложить на пару полей USR_ID и USR_GROUP_ID ограничение первичного ключа?

Если из USR_IN_GROUP нужно будет ссылку делать в другие места, то лучше сделать суррогатный ключ, иначе эта сладкая парочка (а вообще ведь в ключе может быть и больше полей) транзитом разъедется по связанным таблицам, что не очень удобно.

Если из USR_IN_GROUP никаких FK не будет, то можно оставить в ключе парочку, а суррогатный ключ не нужен.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605392
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVОна в одном экземпляре и навечно замкнута на 1-2-3 разработчиков. И ее почти никто не видел. :)

ща разбежался кому-то чёто доказывать. учитывая что все твои аргументы сводятся к «а смотри как там у больших дядек сделано, крупные ERP бла-бла-бла, ко-ко-ко» — если это всё, что ты можешь сказать, то с какого перепугу мои утверждение, что клал я на эти «крупные ERP» с их колхозными костылями, чем-то уступают твоим?

LSV"уровня Галактики" это какбе лол... На экселях при желании/умении тоже можно вести учет "уровня Галактики" (многие так и делают). Т.е. пока этот тезис ниачомъ... :)

как бе лол не лол, но с галактикой мы сотрудничаем. а при желании,.. да мне плевать , можешь хоть на деревянных счётах вести учёт
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605422
Wlr-l
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Serguei, и не только.

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

Пусть у нас будет ID первичным PK и будет уникальный индекс (USR_ID, USR_GROUP_ID). Пусть в таблице USR_IN_GROUP будет строка (5, 1, 1) и из некоторой другой таблицы мы ссылаемся на эту строку.

Давайте сделаем из этой строки такую строку (5, 2, 2), не изменив PK и не нарушив уникальности.

Т.е. мы ссылались на Иванова Ивана Ивановича из группы 1, а стали ссылаться на Петрова Петра Петровича из группы 2.

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

Правильным решением для связи двух таблиц отношением М:М будет создание первичного ключа (уникального индекса) (USR_ID, USR_GROUP_ID) и, может быть, создание индекса (USR_GROUP_ID, USR_ID).

Замечу, что ключ, состоящий из двух полей, один, а не два.
Конечно, можно похвастаться, что наша система состоит из 100500 объектов, а ваша всего из 100.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605440
Сталкивался со схожими проблемами при разработке ряда известных систем различного масштаба для некоторых секретных служб сомнительных заказов.

Данная концепция оказалась сложно реализуемой в блокноте. В совсем запущенных случаях (легаси говнокод на калькуляторе) приходилось прибегать к функциональным возможностям пэйнта и рисовать здоровый красный крестик для обозначения ошибки.

Последующий опыт интеграции с внедрением и запуском различных файлов с расширением "exe" позволяет рассуждать о данных коллизиях не понаслышке, коллега. Это ведь не означает что теперь можно и не доказывать кому-то, но кому? Вот и наша команда, базирующаяся в Калифорнии штат Воронеж затрудняется переводить на русский, но не согласна в корне. А это вообще не дело.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605471
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wlr-lОб уникальности я уже сказал (это когда пользователь говорит о задвоении данных), теперь о целостности (это когда пользователь говорит, что сегодня у этого договора контрагент не тот, что был вчера).

Пусть у нас будет ID первичным PK и будет уникальный индекс (USR_ID, USR_GROUP_ID). Пусть в таблице USR_IN_GROUP будет строка (5, 1, 1) и из некоторой другой таблицы мы ссылаемся на эту строку.

Давайте сделаем из этой строки такую строку (5, 2, 2), не изменив PK и не нарушив уникальности.

Т.е. мы ссылались на Иванова Ивана Ивановича из группы 1, а стали ссылаться на Петрова Петра Петровича из группы 2.
Видим, что глобальные вещи (уникальность, целостность) приносятся в жертву мифической удобности. Сначала нужно говорить о правильности и, если она достигнута, можно говорить о задаче удобства в рамках этой "правильности".

Правильным решением для связи двух таблиц отношением М:М будет создание первичного ключа (уникального индекса) (USR_ID, USR_GROUP_ID) и, может быть, создание индекса (USR_GROUP_ID, USR_ID).


Пойдем в Вашей логике дальше - "давайте сделаем" прямо в таблице USER из Иванова Ивана Ивановича - Петрова Петра Петровича. И пользователь будет говорить, что сегодня у этого договора контрагент не тот, что был вчера!
Вот тебе и целостность! Поэтому ни в коем, ни в коем случае нельзя в таблице USER полагаться на ключ USR_ID - надо обязательно включить в ключ фамилию, имя, отчество... да вообще все поля таблицы. Иначе неправильно!!!!111!

P.S. Вы осознаете, что через несколько лет Вам за эти опусы будет стыдно? Интернет ведь такая штука, написано клавиатурой - не вырубишь рубильником.
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605509
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинПойдем в Вашей логике дальше - "давайте сделаем" прямо в таблице USER из Иванова Ивана Ивановича - Петрова Петра Петровича. И пользователь будет говорить, что сегодня у этого договора контрагент не тот, что был вчера!
Вот тебе и целостность! Поэтому ни в коем, ни в коем случае нельзя в таблице USER полагаться на ключ USR_ID - надо обязательно включить в ключ фамилию, имя, отчество... да вообще все поля таблицы. Иначе неправильно!!!!111!

P.S. Вы осознаете, что через несколько лет Вам за эти опусы будет стыдно? Интернет ведь такая штука, написано клавиатурой - не вырубишь рубильником.

Насчет USER_ID и фамилии.
Пусть у нас есть форма T1 при приеме на работу.
При приеме на работу у сотрудника была фамилия A, после нескольких лет фамилия стала B (почему-то захотел поменять фамилию)
Так вот какая фамилия должна быть при печати формы T1?
Какая фамилия должна быть при печати отчета принятых на работу за N год?

И это самый простой case. :-)
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605519
Wlr-l
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кот Матроскин,

1. Да осознаю, не только через несколько лет, но и прямо сейчас, мне абсолютно фиолетово.

2. «Написано клавиатурой - не вырубишь рубильником» - золотые слова, Вы не пробовали понять, что Вы сами-то написали?

3. «Пойдем в Вашей логике дальше …». Вы, наверно, восхитились собой, какой Вы креативный человек? Нет, Вы всего лишь сморозили глупость и радуетесь этому.

4. Мне почему-то показалось, что «Но почему-то Вы этого» и Вы это один и тот же человек.

5. Последнее, Ваш пост прочитает много людей. Как Вы думаете, что они подумают о Вас?

Удачи всем!
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605538
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulНасчет USER_ID и фамилии.
Пусть у нас есть форма T1 при приеме на работу.
При приеме на работу у сотрудника была фамилия A, после нескольких лет фамилия стала B (почему-то захотел поменять фамилию)
Так вот какая фамилия должна быть при печати формы T1?
Какая фамилия должна быть при печати отчета принятых на работу за N год?

И это самый простой case. :-)У документа есть дата.
У юзера можно (даже нужно) вести логгирование фамилии и вообще всего важного, что может меняться во времени.
Вытаскиваем из лога ФИО на нужную дату.
(профит)
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605577
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

ты можешь упереться сколько хочешь, но вроде бы ты не такой и ожидаемо придешь куда надо как только задача нормальная подвернется (или кто нить фетву даст в виде паттерна "M&MRules")
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605750
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
круто замесили...
мне лично понравился вот этот ответ:

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

у меня все это в прошлом и всяко было, и очень часто жалел что нету тут хотя бы индексированного нумератора, а то и его же в качестве ключа...
- то действительно на связующую таблицу позже вешается паровоз и потом вешалка, когда нихрена вообще нету - любая автоматизация устраивает, а потом входят во вкус и на первое ТЗ валится второе, потом третье...
- то сцуко кому то в голову потом придет - а давайте мля введем графики работы юзеров, то есть не просто Иванов админ, а Иванов админ 25 мая, 26 мая он просто юзер, при наличии ID вруливаем в таблицу дату, номер приказа и проблема решена...
- пока ситуация простая и туманная как у ТС, можно сделать индексированный счетчик, а ключ сделать составной, зато потом можно переиграть куда хош и как хош и нарастить и расширить, в общем больше свобод при минимуме затрат...

ХЗ... в общем когда я создаю любую таблицу, то первое поле в ней FK и уже лет 10 не жалею ни о чем...
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605760
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmagХЗ... в общем когда я создаю любую таблицу, то первое поле в ней FK и уже лет 10 не жалею ни о чем...

Естественно первичный ключ...
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605804
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoshVostt,

ты можешь упереться сколько хочешь, но вроде бы ты не такой и ожидаемо придешь куда надо как только задача нормальная подвернется (или кто нить фетву даст в виде паттерна "M&MRules")

Я следую простому принципу: не плоди сущностей (читай, лишней херни). И всё будет норм. Борьба со сложностью продолжается :)
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39605835
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

не в обиду (берегу тебя :)), просто вы пока детские одноразовые задачи решаете
отбой
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39606113
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wlr-lОб уникальности я уже сказал (это когда пользователь говорит о задвоении данных), теперь о целостности (это когда пользователь говорит, что сегодня у этого договора контрагент не тот, что был вчера).

Пусть у нас будет ID первичным PK и будет уникальный индекс (USR_ID, USR_GROUP_ID). Пусть в таблице USR_IN_GROUP будет строка (5, 1, 1) и из некоторой другой таблицы мы ссылаемся на эту строку.

Давайте сделаем из этой строки такую строку (5, 2, 2), не изменив PK и не нарушив уникальности.

Т.е. мы ссылались на Иванова Ивана Ивановича из группы 1, а стали ссылаться на Петрова Петра Петровича из группы 2.

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

Правильным решением для связи двух таблиц отношением М:М будет создание первичного ключа (уникального индекса) (USR_ID, USR_GROUP_ID) и, может быть, создание индекса (USR_GROUP_ID, USR_ID).

Замечу, что ключ, состоящий из двух полей, один, а не два.
Конечно, можно похвастаться, что наша система состоит из 100500 объектов, а ваша всего из 100.

Ничего не понял из этого трактата :(
...
Рейтинг: 0 / 0
Стоит ли делать отдельное поле для PK?
    #39606145
SergueiWlr-lОб уникальности я уже сказал (это когда пользователь говорит о задвоении данных), теперь о целостности (это когда пользователь говорит, что сегодня у этого договора контрагент не тот, что был вчера).

Пусть у нас будет ID первичным PK и будет уникальный индекс (USR_ID, USR_GROUP_ID). Пусть в таблице USR_IN_GROUP будет строка (5, 1, 1) и из некоторой другой таблицы мы ссылаемся на эту строку.

Давайте сделаем из этой строки такую строку (5, 2, 2), не изменив PK и не нарушив уникальности.

Т.е. мы ссылались на Иванова Ивана Ивановича из группы 1, а стали ссылаться на Петрова Петра Петровича из группы 2.

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

Правильным решением для связи двух таблиц отношением М:М будет создание первичного ключа (уникального индекса) (USR_ID, USR_GROUP_ID) и, может быть, создание индекса (USR_GROUP_ID, USR_ID).

Замечу, что ключ, состоящий из двух полей, один, а не два.
Конечно, можно похвастаться, что наша система состоит из 100500 объектов, а ваша всего из 100.

Ничего не понял из этого трактата :(

Вы столь безапелляционно заявляете со ссылкой на Иванова Ивана Ивановича или Петрова Петра Петровича?

Однако же, было замечено что агрегатное состояние сей изоморфной химеры столь неустойчиво, что от вас потребуется максимально точный момент времени вышеупомянутого заявления для корректного определения смещения по линейке ИвановоИваноИвановичей-ПетровыхПетровПетровичей. Затем и оценим степень достоверности вашего мнения. Может все наоборот!
...
Рейтинг: 0 / 0
25 сообщений из 96, страница 3 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли делать отдельное поле для PK?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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