Хранение сложных структур данных в БД

Возникла такая проблема:
У меня есть N категорий сайтов. У каждого сайта есть M частей. Каждая часть имеет K пар "параметр:значение". На странице это будет выводится наподобие CSS-кода:

Название блока {
параметр:значение;
параметр:значение;
параметр:значение;
}

Таких блоков будет множество у каждой категории.
Возник вопрос в каком виде хранить это в БД.
Придумал 4 варианта, но у каждого есть минусы. Подскажите как поступить
Вот варианты:
Вариант 1:
Каждая категория - таблица. Каждый блок - запись. Есть поле с массивом параметров и поле с массивом их значений. Минус: множество таблиц.

Вариант 2:
1 таблица. Каждый блок - записью. Каждая категория - поле. Минус: проблемы с автоматическим добавлением категорий.

Вариант 3:
1 таблица. Каждый блок - поле. Каждая категория - запись. Минус: проблемы с автоматическим добавлением блоков.

Вариант 4:
1 таблица. Каждая категория - запись. В записи хранится массив блоков, в каждом элементе этого массива блоков есть массив параметров и массив значений. Минус: будут очень тяжелые структуры данных (массив с массивами, в котором тоже массивы).

Как поступить?

0

1 таблица id_category, name_category
2 таблица id_block, id_category, name_block
3 таблица id_item, id_block, key, value

Добавлено через 2 минуты
это если у каждой части(block) может быть только одна категория, и у каждой пары (item) может быть только одна часть

1

alpex, а не будет долго обрабатываться, если пар (items) будет огромное количество в базе?
В таком случае не практичнее будет создать 2 сериализованных массива (один с ключами, второй со значениями) и запихнуть в таблицу , что у вас №2 ?
интересует именно скорость работы

0

огромное количество это сколько?

1

alpex, количество пар будет около 10 000.
Поэтому важно чтоб запрос обрабатывался не слишком долго
Хотя с выражением огромное количество я погорячился.

0

alexandre0sheva, вам надо чтобы все сразу выводилось? Или может попробуете навигацию?

1

мне кажется что 10000 для поиска по индексированному полю не так уж и много, хотя я могу ошибаться
ну сериализуйте массив тогда и записывайте во вторую таблицу, только я непонимаю зачем ключи и значения разносить по отдельным массивам, проще наверное будет тогда загнать в многомерный массив все данные, и сериализовать его, для каждого блока (части) получится многомерный массив со значениями

1

Maksimchikfull, надо сразу, навигация не подойдет


alpex, тогда надо будет ансериализовать 1 массив на 10000 элементов, а потом ансериализовать еще 10000 массивов. Точно не знаю, но кажется, что нагрузка на сервер будет громадная

0

так у вас в каждой части(блоке) по 10000 пар ключ=значение?

Добавлено через 2 минуты
опишите подробнее что у вас там и как, полностью систему

0

alpex, нет. Примерно будет так: 20 категорий. В каждой по 50 блоков. В каждом блоке по 10 пар.
Но меня крайне волнует именно оптимизация скорости работы.

0

загоняете эти 10 пар в массив, сериализуете и помещаете его в поле к соответсвующему блоку
1 таблица id_category, name_category
2 таблица id_block, id_category, name_block, array
Добавлено через 2 минуты
хотя мне почему то кажется, что с тремя таблицами, как я писал первый раз , будет лучше
может кто поумнее чего скажет

1

alpex, точно, спасибо!

0