Станислав Макаров

То, что Vindicar в общем-то правильно назвал "наследованием" в контексте моделирования РБД иногда называют subtype relationship или inheritance hierarchy, можете поискать примеры по этим терминам.

Включив телепатию, предположу, что правильное решение для вашего случая - хронологическая база данных и стандарт SQL:2011 (ну или что-то аналогичное в вашей СУБД - не все вендоры стремятся реализовать этот стандарт буква в букву).

Конкретнее можно будет поговорить, если объясните, что вы понимаете под "историей" и какая у вас СУБД.

Ещё: 1, 2, 3, 4.

Всё дело в понимании предметной области.

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

Ну а дальше всё по классике - например, можно сделать составной первичый ключ у товара, частью которого является ключ продукта. Тут уже всё зависит от того, какая у вас СУБД и насколько в ней удобно работать с нормальными ключами.

Разумеется, это только один из вариантов решения. И только один из аспектов, т.к. встанет вопрос - как хранить различные поля в описании, немного разные в разных продуктах? Ну и прочее.

Если вам нужно прям версионирование - смотрите SQL:2011 и его реализации под нужные вам РСУБД.

Если вам нужна всё-таки репликация, причём между разношёрстными базами и участниками процесса - посмотрите на www.symmetricds.org

What are some examples of using database replication?

Remote offices replicated to a central office
Cross platform database replication between different databases
Replication between on-premise databases and cloud databases
Consolidation of multiple databases into a data warehouse
Regional database replication to improve access times for local users
High availability of a database using a primary and secondary instance

Насчёт конфликтов и "гита для табличных записей" - тут действительно всё непросто, я вот взялся писать диссер на эту тему..

Не знаю как вы собрались делать нормализацию в средстве рисования схем (причём средстве общего назначения), до и судя по всему для вас эту нормализацию сделал кто-то, кто разбирается в этом.
А нарисовать схему, изображённую на доске на фото, вы можете создав новую диаграмму например из шаблона Software -> database_3.xml

id в book_author не нужен. Сделайте нормальный композитный ключ из book_id и author_id, всем будет хорошо (в том числе СУБД).

ERwin Data Modeler, Oracle SQL Developer Data Modeler

tihhanovski вам дело говорит. Это полная лажа - таблицы Child и Parent. В чем их смысл? Каждая таблица (т.е. отношение, говоря математическим языком) - эти некий факт, который может быть истинным для некоторой комбинации атрибутов (и тогда запись в таблице существует), либо не быть истинным (и тогда записи в таблице нет). В чем суть фактов "Ребенок" или "Родитель"? И в том и в другом случае это человек. Т.е. для хранения сведений о человеке нужна только одна таблица, и это таблица Person.

Другое дело, что вы хотите еще хранить сведения о том, кто кому приходится родителем. Поля ParentId в таблице Person будет недостаточно, т.к. зарегистированный родитель может быть один, а может быть двое (или даже ни одного, если в вашем детсаду могут быть сироты). Можно конечно завести два поля - первый родитель и второй родитель, и давать возможность ставить туда NULL, но не факт что это лучшее решение. Вот для целей хранения связи родитель-ребенок (обращаю ваше внимание, что именно СВЯЗИ родитель-ребенок, а не отдельных сущностей "родитель" и "ребенок") можно завести отдельную таблицу вида Parent(ChildId, ParentId), где оба поля - это внешние ключи в таблицу Person и оба поля формируют составной первичный ключ. Тогда вы сможете спокойно заносить и детей и родителей в одну таблицу, а затем связывать их родственными отношениями - у одного ребенка может быть 0, 1 и более родителей (ограничение в 2 человека нужно будет контролировать на уровне приложения), и каждый родитель может иметь любое число детей.

P.S. По поводу того, что данные разные в Child и Parent - дело не в том, что ФИО надо выносить, а в том, что надо отделить общие данные о человеке, и оставить их в таблице Person (кстати, пол человека вы наверняка захотите хранить в Person), а различающиеся данные разместить в других таблицах, например МестоРаботы и МедицинскиеСведения. То, что у родителей есть место работы, а у детей - мед. сведения, это, грубо говоря, стечение обстоятельств. Завтра вам скажут, что медицинскую информацию и для родителей тоже нужно хранить (например, если они посещают здание детсада). Один-два джоина - это более чем адекватный запрос в нормальной нормализованной БД.

martinfowler.com/eaaCatalog/classTableInheritance.html

Вопрос наполовину не понял, у вас с терминологией тяжеловато.

Мое предложение:
- таблица Магазин(id, ...);
- таблица Товар(id, ...);
- таблица ЦенаТовара(id_магазина, id_товара, цена);

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

Хороший пример - сущность "элемент заказа" (OrderItem). Не может быть элемента заказа без самого заказа. Поэтому идентифицирующая связь из отношения "заказ" (Order) отлично тут подойдет. Если у заказа первичный ключ Id, то первичный ключом OrderItem будет, к примеру, такая пара: (OrderId, Number), где OrderId - внешний ключ в таблицу заказов, добавленный идентифицирующей связью, а Number - номер элемента заказа (строки в чеке, если так понятнее), позволяющий иметь несколько заказанных товаров в одном заказе.

Неидентифицирующая связь, соответственно, НЕ добавляет колонки внешнего ключа в первичный ключ. Соответственно, значение внешнего ключа при неидентифицирующей связи может быть как NULL, так и NOT NULL.

У меня есть подозрение что такими запросами можно или убить базу или созадать коллизию при записи\выдаче

MySQL: https://dev.mysql.com/doc/refman/5.0/en/set-transa...
А вот с Кассандрой будет сложнее: www.datastax.com/dev/blog/row-level-isolation

Советую ERWin (коммерческий) и Oracle Data Modeler (бесплатный), а из книг возьмите Дейта для начала.

Таблица post_category(post_id, category_id), вся запись - первичный ключ, post_id - внешний ключ на post.id, category_id - внешний ключ на category.id. Наличие записи (62, 8) в такой таблице означает, что посту 62 присвоена категория 8. Чтобы вытащить все категории поста - делаете select category_id from post_category where post_id = , все посты в категории - select post_id from post_category where category_id = .

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.