|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Подскажите новичку, кто сталкивался...проблема следующая:
нужно создать таблицу, в которой часть полей может являться одномерными массивами записей (напр. типа TINYTEXT), количество которых наперед неизвестно. Например:
PRIMARY_ID ТОВАР КАТЕГОРИЯ,
где поле КАТЕГОРИЯ является списком категорий (с возможностью их добавления и удаления). Конечно можно просто сделать таблицу с заранее объявленной кучей столбцов (КАТЕГОРИЯ_1, КАТЕГОРИЯ_2 и т.п.), но как-то громоздко получается. Есть ли способ получше?
Неактивен
Да, способ получше называется «переход от keyvalue к реляционным базам данных».
Сделайте отдельную табличку для массивов записей, и храните в них помимо данных
id родительской строки. Касательно Вашего примера — нужна та таблица, которую Вы
описали без столбца КАТЕГОРИЯ, таблица категорий, и таблица, которая будет хранить
id из одной и из другой таблиц, обозначающую связь.
Неактивен
Я наверное не совсем точно сформулировал вопрос. Если речь идет о небольшой базе - вроде бы все просто. Можно три таблицы создать, как Вы предложили. Можно поле КАТЕГОРИИ свернуть в строки (т.е. сериализацию сделать) и вообще обойтись одной таблицей. Или объявить столбцы с избыточностью (как в первом посте).
А если ТОВАРов тысячи, а КАТЕГОРИЙ - сотни, скорее всего любая из описанных баз будет нещадно тормозить, если конечно она как-нибудь не упорядочивается внутри. Вот в этом собственно и вопрос: MySQL сама умеет так делать или следует позаботиться об упорядочивании самому при заполнении базы?
Неактивен
Ну, давайте просто посчитаем. Товаров — тысячи. Округлим вверх до 10к.
Категорий — сотни. Округлим вверх до 1к. Пусть каждый товар входит в
каждую категорию, тогда в таблице связей будет
10 000 × 1 000 = 10 000 000 строк. Далее. Каждая строка состоит из двух
целых чисел, каждое по 4 байта. Итого 80 мегабайт. В начале 90х годов
это была бы большая таблица, а сейчас... ну, Вы меня поняли 
Что касается упорядочивания — создайте индексы, и всё будет хорошо.
Неактивен
Страниц: 1
