|
|
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Привет всем. Есть такая проблема. В базе есть некоторое количество словарей (например, месяцы, города, сотрудники и т.п.). Пользователь может выбрать произвольное количество словарей. Соответственно получаем многомерный куб, где каждая сторона куба - это множество значений одного из словарей. Выбрав любую ячейку куба, пользователь может вбить туда произвольное значение. Если бы количество измерений было фиксированным, то нет проблем. Создаем таблицу, в которой первичный ключ состоит стольких столбцов, сколько словарей используется. Но что делать, если количество и тип столбцов выбираются пользователем? Как такую структуру сохранить в базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 17:26 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Приведу пример. Предположим, сотрудник выбрал три словаря: месяцы, города, типы расходов. Получаем трехмерный куб. По одной грани откладываем месяцы, по второй - города, по третьей - типы расходов. Пользователь заполняет те ячейки, которые ему необходимо. Например, ячейка (март, Москва, такси) - 1000 руб. Проблема в том, что размерность куба зависит от того, сколько словарей использует пользователь и может варьироваться от 1 до количества словарей в системе. Так же содержимое ячейки - любой тип, который пользователь выбирает при построении куба. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:05 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
И в чем собственно проблема? Пользователь выбрал измерения? Описал атрибуты? Вот и создайте соответствующую таблицу для этого куба, включая ключ по измерениям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:21 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Если проблема только в первичном ключе, а не лимите колонок в СУБД, то создаем таблицу, в которой первичный ключ - суррогат. При желании, если больше совсем никто не котролирует уникальность при загрузке, создаем уникальный индекс/констрейнт - состоит из стольких столбцов, сколько словарей в базе и успешно допускает NULL. Иначе придется объединять наборы словарей, например тип и назначение расходов - типоназначение расходов (снежинка). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 18:41 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
ModelR... то создаем таблицу, в которой первичный ключ - суррогат. ... И огребем проблему со скоростью доступа к данным. По выделенной таблице тоже будет не все автоматом хорошо, но если складывать все в одну кучу - точно будет весело. ModelRИначе придется объединять наборы словарей, например тип и назначение расходов - типоназначение расходов (снежинка). Ээ... из-за чего "придется"? Ну а объединение словарей - не буду говорить, что это совсем всегда плохо, но к плюсам этого подхода у меня весьма скептическое отношение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 19:02 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
softwarerИ в чем собственно проблема? Пользователь выбрал измерения? Описал атрибуты? Вот и создайте соответствующую таблицу для этого куба, включая ключ по измерениям. Т.е. предлагается динамически создавать новую таблицу? Т.е. для каждого типа куба будет своя? В принципе, я так и думал, но интересно было, есть ли какое-то иное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 01:14 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
друзья зовут меня Красавчег Сёка Ну, дрпустим, решение есть, и что с того? Автору решения на хлеб с маслом будет или как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 01:22 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Сиоко Асахара друзья зовут меня Красавчег Сёка Ну, дрпустим, решение есть, и что с того? Автору решения на хлеб с маслом будет или как? Автору будет большое человеческое спасибо. Если не устраивает, то уж не обессудьте. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 01:32 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleon Сиоко Асахара друзья зовут меня Красавчег Сёка Ну, дрпустим, решение есть, и что с того? Автору решения на хлеб с маслом будет или как? Автору будет большое человеческое спасибо. Если не устраивает, то уж не обессудьте. :-) А ответом будет большое "пожалуйста"! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 02:08 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonНо что делать, если количество и тип столбцов выбираются пользователем? Как такую структуру сохранить в базе? EAV ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 09:35 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
мод paxmeleonНо что делать, если количество и тип столбцов выбираются пользователем? Как такую структуру сохранить в базе? EAV Что-то я слабо представляю, как в данном случае может помочь EAV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 10:37 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
softwarerесли складывать все в одну кучу - точно будет весело.Зависит от размеров кучи. softwarerЭэ... из-за чего "придется"? Дык не влезут скажем некие 1350 размерностей в 1000 колонок некой СУБД. Маловероятно, что у автора из реально столько, но кто знает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 10:54 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonЧто-то я слабо представляю, как в данном случае может помочь EAV. Многомерный куб - это показатель (или группа пок-ей) на пересечении n координат. Каждая координата - справочник. Если куб проектирует пользователь, то каждая размерность это одна запись в таблице БД фиксированной стр-ры + запись со значением показателя, т.е. EAV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 11:02 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
мод paxmeleonЧто-то я слабо представляю, как в данном случае может помочь EAV. Многомерный куб - это показатель (или группа пок-ей) на пересечении n координат. Каждая координата - справочник. Если куб проектирует пользователь, то каждая размерность это одна запись в таблице БД фиксированной стр-ры + запись со значением показателя, т.е. EAV. Что-то я не совсем понял. Не могли бы вы привести пример. Просто в EAV данные сохраняются в таблице со столбцами примерно такого типа : ( objectID, propertyID, value ). Здесь же проблема в том, что в данном случае propertyID - это координата в кубе. Т.е. n значений по n измерениям. Или я что-то не так понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:13 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonЗдесь же проблема в том, что в данном случае propertyID - это координата в кубе. Т.е. n значений по n измерениям. Или я что-то не так понял? Да, все правильно (я у себя так и делаю) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:50 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleon мод paxmeleonЧто-то я слабо представляю, как в данном случае может помочь EAV. Многомерный куб - это показатель (или группа пок-ей) на пересечении n координат. Каждая координата - справочник. Если куб проектирует пользователь, то каждая размерность это одна запись в таблице БД фиксированной стр-ры + запись со значением показателя, т.е. EAV. Что-то я не совсем понял. Не могли бы вы привести пример. Просто в EAV данные сохраняются в таблице со столбцами примерно такого типа : ( objectID, propertyID, value ). Здесь же проблема в том, что в данном случае propertyID - это координата в кубе. Т.е. n значений по n измерениям. Или я что-то не так понял? Не получится.Там ничего не должно быть кроме ссылок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 15:55 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleon( objectID, propertyID, value ) objecttype - тип объекта классификации objectID - ИД объекта классификации propertyID - имя координаты (например - Поставщики) value - значение координаты (ИД Поставщика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:11 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
ModelRЗависит от размеров кучи. Скорее, "теоретически зависит". Практически - при весьма небольших и скоро достижимых размерах кучи зависимость превратится в однозначный результат. ModelRДык не влезут скажем некие 1350 размерностей Понял. Просто изначально не осознал, к чему относится "иначе" в Вашей фразе. Впрочем, вопрос опять же.. скорее теоретический. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:30 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
мод paxmeleon( objectID, propertyID, value ) objecttype - тип объекта классификации objectID - ИД объекта классификации propertyID - имя координаты (например - Поставщики) value - значение координаты (ИД Поставщика) Наверное вы не поняли. в моем случае, например, если выбрано три словаря (месяцы, города, типы расходов), то тогда ячейка куба имеет кооринаты, например (март, Москва, такси), а значение - 1000 руб. Т.е. здесь propertyID - это кортеж из трех значений, а value - значение в ячейке куба. Т.е. propertyID описывает имя property, которое, в данном случае, есть адрес ячейки в кубе. Для 10 словарей координата ячейки описывается 10 значениями и т.п. Поэтому EAV тут не подходит. Или я опять что-то не понял? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 17:59 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Опять же для примера. Для набора (месяцы, города, типы расходов) у нас записи будут такие: март, Москва, такси - 1000 апрель, Москва, гостиница - 5000 Для набора (месяцы, города, сотрудники, типы расходов) у нас будет так: март, Москва, Вася Пупкин, такси - 2000 апрель, Питер, Коля Петров, гостиница - 6000 и т.п. как это укладывается в схему (objectid, propertyid, value) как я понял здесь propertyid - это координата. или вы имели ввиду другое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 18:03 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonмарт, Москва, Вася Пупкин, такси - 2000 как это укладывается в схему (objectid, propertyid, value) Первая строка квоты - раскладывается в пять строк указанного формата с одинаковыми objectid и разными propertyid/value. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 18:09 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
softwarer paxmeleonмарт, Москва, Вася Пупкин, такси - 2000 как это укладывается в схему (objectid, propertyid, value) Первая строка квоты - раскладывается в пять строк указанного формата с одинаковыми objectid и разными propertyid/value. Понятно. Что-то мне подсказывает, что лучше создавать отдельную таблицу под каждое требуемое множество справочников, где завести отдельный столбец для objectid, по одному столбцу под каждую координату, и отдельный столбец под значение. В общем, как вы и советовали в начале. Единственная проблема, что таких таблиц может получиться очень много, а так же использование динамического sql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 19:27 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleon softwarer paxmeleonмарт, Москва, Вася Пупкин, такси - 2000 как это укладывается в схему (objectid, propertyid, value) Первая строка квоты - раскладывается в пять строк указанного формата с одинаковыми objectid и разными propertyid/value. Понятно. Что-то мне подсказывает, что лучше создавать отдельную таблицу под каждое требуемое множество справочников, где завести отдельный столбец для objectid, по одному столбцу под каждую координату, и отдельный столбец под значение. В общем, как вы и советовали в начале. Единственная проблема, что таких таблиц может получиться очень много, а так же использование динамического sql. А вы попробуйте на досуге пофантазировать. Представьте себе, что вы будете жить 150 лет, из которых как минимум 100 будете в творческом полёте. В каком направлении будут развиваться программы по управлению данными, которых много (и без разницы, как эти программы называются, СУБД или как по-другому, разве в этом суть?) Данные, которых много! Вот в этом суть и смысл. Научные методы и теория в их унификации в компьютерных системах устарели или по крайней мере недостаточны. Вы ведь не верите в то, что нынешнее состояние в данной области будет вечно оставаться неизменным? Вот и приступайте. И не флеймите более, отпускаю вам грехи ваши... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2007, 01:43 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonПривет всем. Есть такая проблема. В базе есть некоторое количество словарей (например, месяцы, города, сотрудники и т.п.). Пользователь может выбрать произвольное количество словарей. Соответственно получаем многомерный куб, где каждая сторона куба - это множество значений одного из словарей. Выбрав любую ячейку куба, пользователь может вбить туда произвольное значение. Если бы количество измерений было фиксированным, то нет проблем. Создаем таблицу, в которой первичный ключ состоит стольких столбцов, сколько словарей используется. Но что делать, если количество и тип столбцов выбираются пользователем? Как такую структуру сохранить в базе? 2 варианта: 1. динамически создавать таблицу под куб. 2. Согдать куб по всем измерениям, использовать только некоторые. -- Есть еще вариант, с которым я год работал, и который позволяет в точности то, что Вам надо, но, боюсь, это слишком тяжелое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2007, 19:14 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Сиоко Асахара А вы попробуйте на досуге пофантазировать. Представьте себе, что вы будете жить 150 лет, из которых как минимум 100 будете в творческом полёте. В каком направлении будут развиваться программы по управлению данными, которых много (и без разницы, как эти программы называются, СУБД или как по-другому, разве в этом суть?) Данные, которых много! Вот в этом суть и смысл. Научные методы и теория в их унификации в компьютерных системах устарели или по крайней мере недостаточны. Вы ведь не верите в то, что нынешнее состояние в данной области будет вечно оставаться неизменным? Вот и приступайте. И не флеймите более, отпускаю вам грехи ваши... Не знаю как на счет флейма, но с вашей стороны не было ни одного сообщения по теме в этой ветке. Так что ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 09:32 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
Всем большое спасибо за советы и рекомендации. Премного благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 09:36 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonЕдинственная проблема, что таких таблиц может получиться очень много, а так же использование динамического sql А при EAV будет 2 таблицы на все и статический sql. март, Москва, Вася Пупкин, такси - 2000 затраты 1 количество 2000 затраты 1 месяц март затраты 1 город Москва затраты 1 персона Вася Пупкин затраты 1 транспорт такси где затраты - имя сущности (объекта) 1 - objectID ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 09:41 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
моди статический sql. Который не влезет в ограничения парсера на максимальную длину запроса :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 10:10 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
softwarerКоторый не влезет в ограничения парсера на максимальную длину запроса :) Смотря как писать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 10:41 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
мод softwarerКоторый не влезет в ограничения парсера на максимальную длину запроса :) Смотря как писать :) Кодогенерацию для таких случаев никто не отменял. Работает отлично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:01 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
RA\/ENКодогенерацию для таких случаев никто не отменял. Работает отлично. Ессно, не руками же писать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:19 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
мод RA\/ENКодогенерацию для таких случаев никто не отменял. Работает отлично. Ессно, не руками же писать Имелась ввиду генерация объектов БД (процедур, пакетов, вьюшек) которые содержать большие выборки, "не пролезающие" через парсер запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 13:43 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonОпять же для примера. Для набора (месяцы, города, типы расходов) у нас записи будут такие: март, Москва, такси - 1000 апрель, Москва, гостиница - 5000 Для набора (месяцы, города, сотрудники, типы расходов) у нас будет так: март, Москва, Вася Пупкин, такси - 2000 апрель, Питер, Коля Петров, гостиница - 6000 и т.п. как это укладывается в схему (objectid, propertyid, value) как я понял здесь propertyid - это координата. или вы имели ввиду другое? Я бы сложил все справочники в одну таблицу (пока не видно сильных различий между ними). Дальше сделал работу похожей на EAV, но через промежуточную многие-ко-многим. Пример: Словарь справочников. spravka: id int, type_id int, name varchar(50). Типы справочников. types: id int, type_name varchar(50) Значения: values: id, value. Множество ключей (определяет размерность куба динамически): links: spravka_id, values_id. Тогда март, Москва, такси - 1000 это types: 1, месяц; 2, город; 3, на_что_потрачено. spravka: 1, 1, март; 2, 2, Москва; 3, 3, такси. values: 1, 1000. links: 1, 1; 2, 1; 3, 1. Вносим март, Москва, Вася Пупкин, такси - 2000. дополнительно получаем: types: 4, ФИО. spravka: 4, 4, Вася Пупкин. values: 2, 2000. links: 1, 2; 2, 2; 3, 3; 4, 2. PS ИМХО это система удобна чтобы не заводить новые таблицы при добавлении новых "граней" куба. но нужно будет програмно следить за целостностью. Ваши замечания коллеги? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 15:13 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
А если, например, ограничить размерность куба 20 измерениями и создать таблицу вида: object_id, type1_id, type1_value, type2_id, type2_value, ..., type20_id, type20_value, value и сохранять все записи в ней. Для не используемых типов хранить null. Получиться одна большая таблица на все случаи :-) Минус в том, что ссылочную целостность придется контролировать программно. Эффективнее ли это, чем примеры с EAV, приведенные ранее? И еще, у меня value - на самом деле несколько значений. Т.е. каждая ячейка куба может содержать или одно значение, или множество значений. Например, ячейка (март, Москва, такси) - 1000 руб, 12 числа, комментарий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:01 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
и рядом: ячейка (Москва, март, такси) ячейка (март, такси, Москва) Вряд ли это приемлемо для кубов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 16:48 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
ModelRи рядом: ячейка (Москва, март, такси) ячейка (март, такси, Москва) Вряд ли это приемлемо для кубов. Проблемы есть, согласен. А в плане скорости работы с базой что лучше? Одно большая разряженная таблица или же вариант с EAV? C EAV для каждой координаты будет n + m строк в таблице, где n - размерность куба, а m - колличество значений для координаты. Т.е. для полного куба количество строк будет (кол-во элементов в словаре 1)*...*(кол-во элементов в словаре n)*(m+n). В случае же с одной большой таблицей будет много неиспользуемых ячеек при мало-размерных кубах, но зато строк в таблице будет (кол-во элементов в словаре 1)*...*(кол-во элементов в словаре n) Или это не существенно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:15 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
paxmeleonА если, например, ограничить размерность куба 20 измерениями и создать таблицу вида: object_id, type1_id, type1_value, type2_id, type2_value, ..., type20_id, type20_value, value и сохранять все записи в ней. Для не используемых типов хранить null. Получиться одна большая таблица на все случаи :-) Минус в том, что ссылочную целостность придется контролировать программно. Эффективнее ли это, чем примеры с EAV, приведенные ранее? И еще, у меня value - на самом деле несколько значений. Т.е. каждая ячейка куба может содержать или одно значение, или множество значений. Например, ячейка (март, Москва, такси) - 1000 руб, 12 числа, комментарий Если ячейка куба должна содержать множество значений (наверное есть словарь типов или чего-то близкого), то система изменится: values выродится в id. values_many: id, value_id, data. values: 5; values_many: 7, 5, 1000 рублей; 8, 5, 12 числа; 9, 5, комментарий. Основной принцип тот же: у нас есть множество словарей описываемое slovary и множество links которые позиционируют нашу ячейку относительно измерений. А дальше сама ячейка может быть любой конструкцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:21 |
|
||
|
Хранение многомерного куба (с динамическим количеством измерений) в базе
|
|||
|---|---|---|---|
|
#18+
VoDA Если ячейка куба должна содержать множество значений (наверное есть словарь типов или чего-то близкого), то система изменится: values выродится в id. values_many: id, value_id, data. values: 5; values_many: 7, 5, 1000 рублей; 8, 5, 12 числа; 9, 5, комментарий. Основной принцип тот же: у нас есть множество словарей описываемое slovary и множество links которые позиционируют нашу ячейку относительно измерений. А дальше сама ячейка может быть любой конструкцией. Это понятно. Я хочу узнать по опыту здесь присутствующих, что лучше? Использовать EAV в таком виде или ввести ограничение на размерность куба и количество значений и хранить все в одной таблице в виде: objectid, type1id, type1value, ..., type20id, type20value, value1id, value1value, ..., value10id, value10value Просто судя по существующим решениям и бизнес-области, можно ввести разумные ограничения, например размерность не более 20, количество значений не более 10. Получаем одну разряженную таблицу с большим количеством столбцов. В плане нагрузки на сервер и скорости вставки/модификации/чтения данных какой из двух подходов оптимальнее? Может кто-нибудь проводил сравнения или видел какую-либу инфу на этот счет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2007, 12:45 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1544291]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
251ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 618ms |

| 0 / 0 |
