Это непростой вопрос ... Базы данных SQL не подходят для моделирования иерархии классов.
Вам понадобится хорошая ОРМ.
То, что я поставил иерархию классов в таблице, сделать это:
Сначала я убедиться, что это уместно: например, помещая узлы, статьи и т.д. для веб-CMS в той же таблице, имеет смысл, потому что это все варианты одного и того же.
Идея состоит в том, что вам необходимо создать столбцы базы данных для поиска, индексирования и создания SQL-запросов, но вам не нужно хранить всю свою информацию в столбце базы данных. Вы можете сохранить остальные в сериализованном объекте в столбце BLOB.
В таблице есть - конечно, столбец, который указывает, какой класс этой строки является экземпляром - несколько столбцов «core», которые являются общими для всех классов, в основном полей базового класса. - другие столбцы, которые используются только для некоторых подклассов, но которые мне нужны для поиска, поэтому их нужно индексировать - BLOB, который содержит все другие данные от объекта.
В основном, когда я храню объект в базе данных, соответствующие столбцы в соответствии с его классом заполняются, а остальные данные (или даже весь объект) запихиваются в BLOB.
Замечательно, что если вы добавите значение члена, которое не нужно искать или индексировать, оно сохраняется только в столбце базы данных, поэтому вы не вносите никаких изменений в база данных вообще: она будет храниться в сериализованном BLOB. Единственное, что нужно сделать, это добавить значение по умолчанию для этого члена в код десериализации, поэтому объекты этого класса, которые уже находятся в базе данных и не имеют этого члена, будут иметь для него достойное значение по умолчанию.
Вы также можете изменить свои форматы объектов, если хотите, он становится более сложным.
Однако эта схема имеет некоторые недостатки:
Ограничения трудно применять: - вы можете применять только ограничения на поля, которые имеют столбец. - поскольку некоторые столбцы встречаются только с некоторыми классами, база данных должна знать немного о вашей иерархии классов.
Например, вы, вероятно, захотите поместить адреса в отдельную таблицу и добавить соответствующие поля (почтовый индекс, страну, улицу, номер и т. Д.): Все это в вашей основной таблице будет содержать слишком много столбцов. Кроме того, вы в какой-то момент захотите добавить некоторых Клиентов или другие вещи, которые находятся в другой таблице, а также иметь адрес, поэтому лучше поместить адрес в отдельную таблицу и ЗАПИСАТЬ их.
То же самое для людей или компаний, и т.д.
Теперь магазин имеет адрес, но телега не, я полагаю, так что вам придется выразить в DDL базы данных, что строка из таблицы должен ссылаться на адрес, если он имеет тип «магазин», но не типа «cart».
Это может стать немного волосатым.
Также, если у вас есть 10 магазинов и 100 000 тележек, для работы может быть интересно разбить столы, чтобы вы получили хороший маленький быстрый стол и один большой стол.
Теперь есть и другие решения:
Например, вы могли бы поставить все кода и базовые элементы базового класса, но делают TABLENAME атрибут класса, который изменяется в производном классе. Таким образом, просто изменяя имя таблицы, весь код применяется к другой таблице, но вам не нужно переписывать ее.
Затем вы получаете 1 стол за класс.
Вы можете, конечно, применить метод выше для каждой таблицы, если иерархия классов становится более сложной.
Как выбрать между двумя?
В принципе, если вы делаете веб-CMS и хранить в таблице, объекты классов, производных от узла, как: - Статья - изображение с легендой - Галерея - и т.д.
Все эти объекты являются в основном то же самое. Все они имеют заголовок, поле TextContent, принадлежат к ParentNode и т. Д.
Если вы выполняете поиск по ключевому слову для «foo» в TextContent, это намного проще, если все объекты находятся в одной таблице.
Если вы хотите перечислить всех дочерних элементов ParentNode для отображения их на веб-странице, это также намного проще, если все в одной таблице.
Так что в этом случае первый метод действительно является преимуществом.
Теперь в вашем случае объекты не похожи.
Лично я бы даже не дал им тот же базовый класс. Я бы создал имена Mixin «ThingWithCoordinates» (возможно, что-то короче) и добавьте это в классы.
Теперь, возможно, пекарня достаточно близко к Магазину, который он может унаследовать от него, но телеги и стойки, возможно, нет.
В вашем случае я бы определенно использовал несколько таблиц. И в каждой таблице, если вам нужно сохранить несколько классов, я бы использовал первый метод.
Главное, что ваша иерархия классов (и, следовательно, таблицы) должна основываться на чем-то RELEVANT (автодилеры и пекарни - это магазины), а не общие черты, которые существуют между объектами, которые фактически не имеют ничего общего (например, тележка и магазин). Для этого существуют миксины для совместного использования общего кода, но не базовые классы.