ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
7 сообщений из 7, страница 1 из 1
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #38959824
AlexSSSS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexSSSS
Участник
XML - в кавычках ибо не знаю как правильно называется (подсматривал в БД программы Супермаг УКМ - там в подобном виде хранятся параметры товаров)
Итак, дано:
Описание БД
 

таблица ВИДЫ_ОБОРУДОВАНИЯ:
Код: sql
1.
2.
ID
Название


храним
1 СИСТЕМНЫЙ БЛОК
2 ПРИНТЕР
3 МОНИТОР
таблица ТИПЫ_ОБОРУДОВАНИЯ
Код: sql
1.
2.
3.
ID
ID_вида_оборудования
Название


Храним:
1 1 Маленький СБ
2 1 Синий СБ
3 2 Быстрый принтер
3 2 Струйный принтер
Таблица НАЗВАНИЯ_ПАРАМЕТРОВ_ВИДА_ОБОРУДОВАНИЯ
Код: sql
1.
2.
3.
ID
ID_вида_оборудованя
Название


Храним:
1 1 Процессор
2 1 Память
3 2 Тип
4 2 Фирма
Таблица ЗНАЧЕНИЯ_ПАРАМЕТРОВ_ВИДА_ОБОРУДОВАНИЯ
Код: sql
1.
2.
3.
4.
ID
ID_типа_оборудования
ID_названия_параметра_вида_оборудования
Значение


Храним:
1 1 1 Целерон
2 1 2 4 Гб
3 2 1 Атом
4 2 2 2 ГБ
5 3 3 Тонерный
6 3 4 Киосера
7 4 3 Струйный
8 4 4 Епсон

Идея в следующем: таблицы НАЗВАНИЯ_ПАРАМЕТРОВ_ВИДА_ОБОРУДОВАНИЯ и ЗНАЧЕНИЯ_ПАРАМЕТРОВ_ВИДА_ОБОРУДОВАНИЯ заменяем на ПАРАМЕТРЫ_ВИДА_ОБОРУДОВАНИЯ:
Код: sql
1.
2.
3.
4.
ID
ID_ВИДА_ОБОРУДОВАНИЯ
ID_ТИПА_ОБОРУДОВАНИЯ
ПАРАМЕТР


Храним в следующем виде:
1 1 1 <назв_парам>ПАМЯТЬ</назв_парам><знач_парам>4 Гб</знач_парам>
2 1 1 <назв_парам>ПРОЦЕССОР</назв_парам><знач_парам>Целерон</знач_парам>
3 1 2 <назв_парам>ПАМЯТЬ</назв_парам><знач_парам>2 Гб</знач_парам>
4 1 2 <назв_парам>ПРОЦЕССОР</назв_парам><знач_парам>Атом</знач_парам>
5 2 3 <назв_парам>Тип</назв_парам><знач_парам>Тонерный</знач_парам>
6 2 3 <назв_парам>Фирма</назв_парам><знач_парам>Киосера</знач_парам>
7 2 3 <назв_парам>Тип</назв_парам><знач_парам>Струйный</знач_парам>
8 2 3 <назв_парам>Фирма</назв_парам><знач_парам>Епсон</знач_парам>

Вопросы:
1. Даст ли такая структура возможность "на лету" добавлять свойства?
2. Уменьшится-ли "геморрой" при поисках (с EAV-ом, помнится, замучился "выковыривать" нужную информацию - спасали временные таблицы)?
3. Наверняка эта технология применяется - как она называется правильно и что почитать?

З.Ы. Избыточность "ID_ВИДА_ОБОРУДОВАНИЯ" облегчит поиск списка свойств для вида оборудования. Например, список параметров для системных блоков (MySql):
Код: sql
1.
select distinct ExtractValue(k.ПАРАМЕТР,'/назв_парам') from ПАРАМЕТРЫ_ВИДА_ОБОРУДОВАНИЯ k where k.ID_ВИДА_ОБОРУДОВАНИЯ=1
...
Рейтинг: 0 / 0
15.05.2015, 14:02
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #38959878
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
В XML можно хранить то, что не придется искать.
Для хранения важной инфы - плохой вариант. Тормоза. Возможна несовместимость между разными СУБД.

Не вижу особых проблем с EAV при поиске. Точнее проблемы такие же как в любом другом решении.
...
Рейтинг: 0 / 0
15.05.2015, 14:43
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #38960127
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
XML выгоден, если он УЖЕ применяется - то бишь от поставщика вы получаете XML заказчику отсылаете XML и т.д.
И я согласен с LSV - надо смотреть на реализацию от конкретной СУБД конкретной версии.
AlexSSSS 1. Даст ли такая структура возможность "на лету" добавлять свойства?Да
AlexSSSS 2. Уменьшится-ли "геморрой" при поисках (с EAV-ом, помнится, замучился "выковыривать" нужную информацию - спасали временные таблицы)?Чудес не бывает. Для SQL Server создание первичного XML индекса это и есть построение временной таблицы "под капотом". Чтобы поиск был быстрым надо индексировать. Насколько это геморройнее EAV не знаю.
AlexSSSS 3. Наверняка эта технология применяется - как она называется правильно и что почитать? http://en.wikipedia.org/wiki/XQuery
...
Рейтинг: 0 / 0
15.05.2015, 17:24
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #38960153
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
AlexSSSSXML - в кавычках ибо не знаю как правильно называется

Сообщение не читаю, отвечаю на вопрос в заголовке темы:

XML вместо EAV ?

Я бы сказал -- нет, ни в коем случае.
EAV имеет относительно XML одну очень важную особенность: он не нарушает 1НФ, т.е. является полностью реляционным решением.
XML же, наоборот, таким решением не является, он строго контрреляционный. Нарушает 1НФ, и не может быть обработан с помощью SQL.

Так что если выбирать между EAV и XML, то выбор очевиден -- только EAV.

Но, как тут уже правильно сказали, возможны варианты -- если какую-то информацию не нужно обрабатывать внутри БД, или есть хорошие средства обработки XML внутри СУБД (а лучше и то и другое сразу), то можно кое-что и в XML хранить.
...
Рейтинг: 0 / 0
15.05.2015, 17:41
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #38960159
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Вопросы:
1. Даст ли такая структура возможность "на лету" добавлять свойства?

Видимо, да (если я правильно понял идею структуры). Но не понятно, почему у тебя в XML по одному параметру только, а не много.

2. Уменьшится-ли "геморрой" при поисках (с EAV-ом, помнится, замучился "выковыривать" нужную информацию - спасали временные таблицы)?

Нет, напротив, он увеличится. Вряд ли в твоей СУБД будут сквозные индексы по таблице на все поля внутри XML.
Собственно, в EAV особенного гемороя и нет, просто немного сложнее писать запросы.

3. Наверняка эта технология применяется - как она называется правильно и что почитать?

Никак.
...
Рейтинг: 0 / 0
15.05.2015, 17:44
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #39012548
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
AlexSSSS,
лучше взять PostgreSQL и посмотреть на jsonb в качестве метода хранения.

А какой объем данных? Сколько атрибутов, сколько объектов, какие требования к производительности? А то для небольшого магазинчика вообще все равно, как хранить.
...
Рейтинг: 0 / 0
21.07.2015, 16:51
| Ответить | Цитировать | Написать  
XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
    #39012668
babona
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
babona
Участник
автор,
лёгких решений по каталогу номенклатуре продуктов не бывает

Вы только в начале пути
...
Рейтинг: 0 / 0
21.07.2015, 19:06
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / XML" вместо EAV ? (БД, инвентарный учет, свойства инв. еденицы - разное количество)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38960153&tid=1540513]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 164ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 45ms
get tp. blocked users:
 1ms
others: 14ms
total:  267ms
созд. / загр.: 267ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]