База данных значений атрибутов сущностей против строгой реляционной модели электронной коммерции
Я использовал функцию jquery (toggleClass), чтобы изменить цвет div при наведении курсора
<!DOCTYPE html>
<html>
<head>
<title></title>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<style type="text/css">
.b1{
background:red;
width: 30px;
height: 40px;
margin: 10px;
}
.b{
background:blue;
width: 30px;
height: 40px;
margin: 10px;
}
</style>
</head>
<body>
<div class="b1"></div>
<div class="b1"></div>
<div class="b1"></div>
<div class="b1"></div>
<div class="b1"></div>
<script type="text/javascript">
$('div').hover(function () {
// body...
$("div").toggleClass("b");
});
</script>
</body>
</html>
4 ответа
There's a few general pros and cons I can think of, there are situations where one is better than the other:
Option 1, EAV Model:
- Pro: less time to design and develop a simple application
- Pro: new entities easy to add (might even be added by users?)
- Pro: "generic" interface components
- Con: complex code required to validate simple data types
- Con: much more complex SQL for simple reports
- Con: complex reports can become almost impossible
- Con: poor performance for large data sets
Option 2, Modelling each entity separately:
- Con: more time required to gather requirements and design
- Con: new entities must be modelled and designed by a professional
- Con: custom interface components for each entity
- Pro: data type constraints and validation simple to implement
- Pro: SQL is easy to write, easy to understand and debug
- Pro: even the most complex reports are relatively simple
- Pro: best performance for large data sets
Option 3, Combination (model entities "properly", but add "extensions" for custom attributes for some/all entities)
- Pro/Con: more time required to gather requirements and design than option 1 but perhaps not as much as option 2 *
- Con: new entities must be modelled and designed by a professional
- Pro: new attributes might be easily added later on
- Con: complex code required to validate simple data types (for the custom attributes)
- Con: custom interface components still required, but generic interface components may be possible for the custom attributes
- Con: SQL becomes complex as soon as any custom attribute is included in a report
- Con: good performance generally, unless you start need to search by or report by the custom attributes
* I'm not sure if Option 3 would necessarily save any time in the design phase.
Personally I would lean toward option 2, and avoid EAV wherever possible. However, for some scenarios the users need the flexibility that comes with EAV; but this comes with a great cost.
Можно с уверенностью сказать, что модель базы данных EAV / CR плохая.
Нет, это не так. Просто они неэффективно используют реляционные базы данных. Чистое хранилище ключей / значений отлично работает с этой моделью.
Теперь, к вашему настоящему вопросу: как хранить различные атрибуты и сделать их доступными для поиска?
Просто используйте EAV. В вашем случае это будет одна дополнительная таблица. индексируйте его как по имени атрибута, так и по значению, большинство RDBM будет использовать сжатие префикса для повторений имени атрибута, что делает его действительно быстрым и компактным.
EAV / CR становится некрасивым, когда вы используете его для замены «реальных» полей. Как и в случае с любым другим инструментом, злоупотребление им является «плохим» и создает плохой имидж.
Я борюсь с этим же вопросом. Вам может быть интересно прочитать следующее обсуждение двух существующих решений для электронной коммерции: Magento (EAV) и Joomla (регулярная реляционная структура): https://forum.virtuemart.net/index.php?topic=58686.0
Похоже, что работа Magento с EAV - это настоящий шоустоппер.
Поэтому я склоняюсь к нормализованной структуре. Чтобы преодолеть недостаток гибкости, я подумываю о добавлении в будущем отдельного словаря данных (XML или отдельных таблиц БД), который можно было бы редактировать, и на основе этого вместе с SQL-скриптами будет сгенерирован код приложения для отображения и сравнения категорий продуктов с новым набором атрибутов.
Такая архитектура в данном случае кажется сладостной - гибкой и одновременно производительной.
Проблемой может быть частое использование ALTER TABLE в живом окружении. Я использую Postgres, поэтому его MVCC и транзакционная DDL, надеюсь, облегчат боль.
.Я все еще голосую за моделирование на самом низком значимом атомарном уровне для EAV. Разрешить стандартам, технологиям и приложениям, ориентированным на определенное сообщество пользователей, определять модели контента, необходимость повторения атрибутов, гранул и т. Д.