Проанализируйте входные данные и посоветуйте

[Кощей]

Проанализируйте входные данные и посоветуйте

У меня есть задача организовать объектное хранилище данных и сделать это максимально производительно.
Объект немного громко сказано, мне просто нужно иметь запись в которую можно вкладывать другие записи различных типов, как масивы, хеши, скаляры, инты и флаги или файлы.
Пример объекта

/store/
{
    settings => {name => 'Some name', phone => '123456'},
    sales => { some_id  => {amount => '30%', date => '06.11.2008'},
               some_id2 => {amount => '50%', date => '01.12.2008'}},
      picture => *logo.png*,
      brands => [43243, 13443, 93244, 4324, 765]
}

-~{}~ 11.08.08 20:05:

Я предпологал изначально сделать таблицу с записями об объектах и вторую таблицу с атрибутами.
первая таблица объекта: id, name
вторая: object_id, attribute, value

Но вот с типом данных для value второй таблицы непонятно, делать текстовый но таким образом нормальной выборки фильтром по этому полю не выйдет

-~{}~ 11.08.08 20:26:

Как)

 

[Gas]

Ну если нужен и поиск по атрибутам, могу посоветовать EAV
+ поиск на тему универсальный каталог. Но реализация врят-ли получится простой.

 

[Кощей]

Нужна выборка по атрибутам, причем шустрая)
Сейчас почитаю топики, выскажу мысль может отбросите сразу как тупую)

Делать все записи через специально написанный драйвер, а структуру таблицы атрибутов сделать такой:
object_id - какому объекту атрибут принадлежит
name - имя атрибута
type -тип атрибута ( строка, инт, другой объект, блоб для файла) для каждого типа иметь ячейку такого типа
string (varchar)
text (text)
object (id айдишник аналогичного объекта)
file (bool)

Ну и когда драйверу говориш отобрать атрибуты объекта он будет брать атрибут смотреть его тип и брать данные только из нужной ячейки.
Может вы уже видите минусы такого подхода, посоветуйте пожалуйста.

 

[Gas]

вполне приемлемый вариант.

а у объектов не будет конечного срока жизни, ну там пару дней?

 

[Кощей]

Gas
Пока таких требований не вижу, может еще у каждого атрибута еще сделать обязательные поля add_time и upd_time для реализации таких особеностей в будущем

 

[Gas]

я просто спросил, вдруг эти объекты будут быстро "умирать", тогда количество актуальных оставалось не слишком большим чтоб искать like'ом и не париться

 

[Кощей]

По плану объектов будет тысячи тысяч и умирать они тоже не должны, вообще ничего удаляться не должно, только атрибуты меняться.

 

[Gas]

Понятно, от 5M записей в таблице атрибутов. Индексы + памяти под нужные буферы и должно быстро работать.

 

[Beavis]

используй ORM

 

[Gas]

Beavis
каким образом он то тут поможет, по крайне мере стандартные реализации типа доктрины или пропела?
Тут нет как такого relational, а mapping идёт произвольного и заранее неизвостного набора атрибутов.

Кощей
хотя если столько записей, может и лучше будет разнести разные типы объектов по отдельным таблицам. Стоит определиться с полным перечнем возможных запросов, заполнить табличку хотя бы миллионом записей и уже на основе тестов делать выводы.

 

[Кощей]

Столкнулся с необходимостью ограничить возможность создания объектов с одинаковым именами на одном уровне.
Получается в таблицу object нужно записывать id родительского объекта чтобы сделать уникальный индекс, хорошо ли это ?

 

[Gas]

хорошо ли это

если это решит проблему, то нормально.