Наследование в проектировании баз данных
Конструктор jQuery принимает 2-й параметр, названный context , который может использоваться для переопределения контекста выбора.
jQuery("img", this);
, Который совпадает с использованием .find() как это:
jQuery(this).find("img");
, Если imgs Вы требуете, только [1 112] прямые потомки нажатого элемента, можно также использовать .children() :
jQuery(this).children("img");
5 ответов
На самом деле описанная вами схема (общая таблица плюс таблицы для конкретных подтипов) называется Наследование таблицы классов .
Наследование конкретной таблицы привело бы к дублированию всех общих атрибутов в таблицах подтипов, и у вас не было бы таблицы супертипов, как сейчас.
Я категорически против EAV. Я считаю это антипаттерном SQL. Это может показаться элегантным решением, потому что для него требуется меньше таблиц, но вы настраиваете себя на большую головную боль позже. Вы определили пару недостатков, но есть много других. IMHO, EAV используется надлежащим образом только в том случае, если вы абсолютно не должны создавать новую таблицу, когда вводите новый подтип, или если у вас есть неограниченное количество подтипов (например, пользователи могут определять новые атрибуты ad hoc).
У вас много подтипов, но все же их конечное число, поэтому, если бы я делал этот проект, я бы придерживался Наследование таблицы классов . У вас может быть несколько строк каждого подтипа, но, по крайней мере, у вас есть некоторая уверенность в том, что все строки в каждом подтипе имеют одинаковые столбцы, вы можете использовать NOT NULL , если вам нужно, вы можете использовать типы данных SQL, вы можете использовать ограничения ссылочной целостности и т. д. С точки зрения отношений это лучше, чем EAV.
Еще один вариант, о котором вы не упомянули, называется Serialized LOB . То есть добавьте столбец BLOB для полуструктурированной коллекции настраиваемых атрибутов. Сохраните XML, YAML, JSON или ваш собственный DSL в этом столбце. Вы не сможете легко анализировать отдельные атрибуты из этого большого двоичного объекта с помощью SQL, вы Вам нужно будет загрузить весь большой двоичный объект обратно в приложение и извлечь отдельные атрибуты в коде. Так что в некотором смысле это менее удобно. Но если это удовлетворяет ваше использование данных, то в этом нет ничего плохого.
Я думаю, это в основном зависит от того, как вы хотите использовать эти данные.
Во-первых, я не вижу преимущества варианта 3 перед вариантом 2. Я думаю, что разделение специальные таблицы в другой схеме усложнят поддержку вашего приложения, особенно если позже будут обнаружены общие черты между «особыми значениями».
В качестве другого варианта я бы сказал: - Сохраните специальные значения во фрагменте XML (или большом двоичном объекте). Большинство баз данных в наши дни имеют возможность запрашивать структуры XML, поэтому без необходимости во многих дополнительных таблицах вы сохраните свою гибкость для небольшого снижения производительности.
Если вы поместите все специальные значения в одну таблицу, вы получите очень разреженная таблица. Большинство обычных СУБД не могут справиться с этим очень хорошо, но есть некоторые реализации, которые специализируются на этом. Вы могли бы извлечь из этого пользу.
Часто ли вам нужно запрашивать пары ключ-значение? если вы в основном получаете доступ к этой таблице через entry_id, я думаю, что наличие таблицы ключ-значение - неплохой дизайн. Дополнительный индекс в столбце kay может даже помочь вам, когда вам нужно запросить специальные значения. Если вы создаете уровень приложения поверх своей базы данных, таблица ключ-значение будет отображаться в структуре Map или Hash, который также можно легко использовать.
Это также зависит от различных типов значений, которые вы хотите сохранить. Если существует много разных типов, к которым нужно легко получить доступ (вместо сериализации / десериализации в XML / Character-String), вы можете сохранить тип в отдельном столбце, но это обычно приводит к очень сложному дизайну.
Надеюсь, это поможет (немного).
-Мартен
http://en.wikipedia.org/wiki/Entity-Attribute-Value_model
Предлагаем вам прочитать о проблемах с таблицами значений сущностей, прежде чем принимать решение об их использовании.
Oracle неплохо справляется с редко заполненными таблицами. Я думаю, вы можете использовать тот же подход, что и компания Salesforce. Они используют таблицы с большим количеством столбцов, при необходимости они создают столбцы. Вы можете индексировать эти столбцы намного лучше, чем модель eav.
Таким образом, он гибкий, но работает лучше, чем модель eav.
Прочтите: Спросите Тома 1 , Спросите Тома 2 , Высокая масштабируемость и SalesForce .
Шаблоны «Вариант 1» также называют «Универсальным отношением». На первый взгляд кажется, что это короткий путь к тому, чтобы не выполнять потенциально сложное моделирование данных. Он торгует простым моделированием данных за невозможность простого выбора, обновления и удаления без значительно больших усилий, чем это потребовало бы более привычной модели данных с несколькими таблицами.