Ситуация такая. У нас разные источники информации. Один из воспоминаний автора а второй по информации от соседей. Оба этих источника говорят что книгу 1 наипсал автор 2 источники разные
Итого получаем
Книга Автор Источник
1 2 5
1 2 6
У нас при удалении используется два поля
Удалить книгу 1 с автором 2
В этом случае удалятся две записи. Удаление по двум ключам нас после добавления источника уже не устроит. Такая же ситуация и с модификацией.
Так и это еще не все. Как правило подобных мелких задач десятки по всему проекту и они накапливаются лавинообразно. После какого то критического их количества уже нет человека который может сказать что вообще происходит. А дел то всего — не ставили в начале сурогатные (автоинкрементные) ключи. Сурогатный — искусственно введенный но не уникальный. Автоинкрементный — уникальный.
функционал к примеру админской части модифицирующий или удаляющий записи по двум ключам которые до ввода нового правила вас устраивали. А есть еще пользовательские интерфейсы которые также используют два ключа. Получается что вам легче все убить чем переделывать. Одна крохотная ошибка допущенная в начале утверждением что нам это никогда не понадобится привела к фатальной ошибке со временем. Так разработчики и ограничивают себя в росте. На каком то этапе возникают проблемы через которые приложение не может переступить и вынуждены писать костыли чтобы оно не развалилось. Не все приложения могут себе позволить столь масштабный рефакторинг.
Давайте продолжать. У вас уже есть некий функционал, который выгребает значения используя два поля. Сейчас это уже потенциально ошибка. Используй вы сурогатный автоинкрементный ключ таких проблем не возникло бы. И таких примеров масса. Все правильно все рано или поздно приходит к сурогатному первичному ключу как вы его назвали. Мы разговариваем об одном и том же называя по разному.
Все верно я о нем родимом. Даже не представляю как можно работать без «сурогатного идентификатора» удивляюсь, когда на моем пути встречаюся люди его не использующие. В таблице BookAuthor все хорошо, пока вы не начали с ней работать. Как только потребуется добавить туда свойст каких то как вариант время добавления записи, кто сделал эту запись. Дальнейший путь модификации может быть следующий это то что пришло в голову — у книги не один автор требуется добавлять несколько авторов. Или к примеру такая ситуация. Из разных источников данные могут разнится и следует хранить оба варианта В этом случае ваши ключи теряют смысл. Все возвращается к автоинкременту ну или к жуткой неразберихе с кодами. Для полной картины требуется добавить вторичный ключ источника откуда она получина. И первые два ключа уже не могут обеспечить уникальность. Изменение одного бизнес правила, и вся логика летит к чертям.
Вам не понадобится автоинкремент только в одном случае. Если не придется ничего делать. Как только с таблицей происходит хоть какая то работа, возникает необходимость в использовании чего то удобного и уникального не имеющего возможность изменяться по прихоти редактора. Опять же возврщаемся к тому что все меняется и скорее рано или поздно нам понадобится и менять структура данных и всегда идентифицировать любую из записей. Человек который говорит что ему это никогда не понадобится просто недальновидный. Любая мелкая ошибка заложенная на ренней стадии проектирования выливается в огромную проблему на поздней.
Есть еще Составные первичные ключи https://habrahabr.ru/post/193284/ ключ не обязательно один их может быть хоть три. Это извращение, к которому приходится прибегать чтобы не использовать автоинкремент а однозначно уникальных полей нет.
Можно и не по автоинкременту. Но надо как вы обеспечите уникальность? Вся прелесть автоинкремента в качестве первичного ключа в том, что он избавляет от неминуемой борьбы со сложностями. Однозначной идентификацией, необходимостью к чему то привязываться. Автоинкремент не обязателен. Вы не растаите бд не перестанет работать, но делать это станет сложнее
Не просто первичное а автоинкрементное. Данное поле должно обеспечивать уникальность в рамках таблицы. Вот когда встречаешь людей, которые подобных вещей не используют а придумывают костыли чтобы задавая по два или три первичных ключа (не автоинкрементных)
Что 1? Отсортировать мы не можем так как нет различающихся данных. В любом случае порядок вывода записей в выборке не будет определен. При двух запросах первым может быть второй, а во втором случае подругому. В базах данных поумнее у нас есть gid однозначно определяющий в бд запись. Но в mysql такого нет. Тут и приходит на помощь автоинкремент.
Идентифицируйте мне однозначно вторую запись в таблице.
Предположим что разработчик который делал эту таблицу посчитал что ему у него не будет подобных записей, но в результате каких то стечений обстоятельств она появилась.
Это из разряда не обязательных, но удобных вещей. Как бы можно под дождем и без зонта ходить никто не растает. Но с зонтом сухо и приятно. Для меня автоинкрементное поле это прежде всего уникальная идентификация записи. Возможность в любом месте использовать независим от структуры самой таблицы. Когда такого поля нет привязаться не к чему. Опять же вы всегда можете добавить два ключ по двум полям с добавлением их уникальности, но это превратит в ад вашу жизнь в случае изменения бизнес логики которая как озвучили выше меняется часто. Каждое такое но, это потенциальный сбой на поздних этапах работы приложения и чем их больше, тем они вероятнее. Автоинкрементное поле однозначно избавляет от озвученных ситуаций. Если вы для себя не объяснили почему вам нужно автоинкрементное поле, я вам не смогу привести убедительные аргументы.
Бритва_Оккама В моем случае структура модели лишнее звено. Предпочитаю не плодить сущности и если есть возможность обойтись без них то так и будет сделано. Причин определять модуль не могу для себя объяснить. Зачем это делать если можно не делать? К тому же не исклчается ситуация когда модель будет описана, но по какой то причине не использоваться в коде. Куски время от времени выкидываются из приложения. В этом случае за собой тянутся зависимости кода друг от друга и неиспользуемые его части.
Я так понимаю то, что вы написали это лишь верхняя часть айсберга который нужно предварительно описать и задать структуру связей. Это и есть сложность. В моем случае это все те же две строки чуть длиннее в которых я через запятую перечисляю какие ключи использовать для связи. Изменение в моем случае потребует через запятую перечислить другие ключи а в вашем полный пересмотр всей концепции и правил приложения, изменение и описание всех вариантов связей. В момем случае удаление данного куска не оставит и намека на то, что он когда то был в коде в вашем все описания никуда не денутся и будут болтаться мертвым грузом каждый раз натыкаясь на них поднимая сомнения, а вдруг где то в коде осталось то, что использует эти конструкции.
Это из разряда магии? Для меня это не так наглядно как для вас. Связей может быть даже не две а пять к примеру. Для каждой у вас реализована своя модель? Каким образом вы определите по вторичному ключу вы обращяетесь от модули к марке, через промежуточную таблицу или по вторичному ключу от марки к модели если каждый ключь реализует свою логику и узкоориентированную связь в бизнес логике.
Итого получаем
Книга Автор Источник
1 2 5
1 2 6
У нас при удалении используется два поля
Удалить книгу 1 с автором 2
В этом случае удалятся две записи. Удаление по двум ключам нас после добавления источника уже не устроит. Такая же ситуация и с модификацией.
«name»=>«Предмет», «Свойство»=>«Много»
«name»=>«Предмет», «Свойство»=>«Много»
)
Идентифицируйте мне однозначно вторую запись в таблице.
Предположим что разработчик который делал эту таблицу посчитал что ему у него не будет подобных записей, но в результате каких то стечений обстоятельств она появилась.
Марки не имеющие моделей = array_diff_key(rb('marks']), rb('marks', «id», «id», rb('models', «marks_id»)))
Исключаем из списка марк те, которые имеют модели