Я должен пойти с одной из двух табличных схем,
SELECT *
FROM 'posts'
WHERE 'id' = '1'
----
id title content col1 col2 col3
1 Title1 Content1 A B C
SELECT p.*, GROUP_CONCAT(c.'col' ORDER BY 'col_number') AS cols
FROM 'posts' p
LEFT JOIN 'cols' c ON c.'pid' = p.'id'
WHERE p.'id' = 1;
----
id title content cols
1 Title1 Content1 A,B,C
В обоих случаях я ограничиваюсь только three cols
для каждой записи в post
таблицы и собирает их как array
как во второй схеме A,B,C
Имеет ли значение, какая схема используется для производительности?
Я знаю, что:
Первая схема может иметь NULL
на col2, col3
.
Вторая схема не будет иметь NULL cols
если только некоторые из столбцов были обновлены до NULL
после того, как value
до Except col_number = 1
ROW
.
В обоих случаях оба они будут иметь значения NULL cols
, коды NULL cols
второй схемы могут быть DELETED
, но я не знаю. Если лучше сохранить его или DELETE
их.
Коротко: какая схема лучше для производительности? Лучше ли держать NULL col
во второй схеме или DELETE
их?
Вы никогда не должны хранить списки вещей в виде строк с разделителями. Период. Вы можете хранить их как JSON или XML или использовать какой-либо другой метод, но сохранение нескольких значений в строке - плохая идея.
Следовательно, первым методом является лучший метод. Что касается производительности, они должны быть похожими на основные запросы. Первый позволяет создавать индексы для каждого столбца, что может быть полезно для некоторых целей.
Использование пространства довольно похоже. Вы говорите о байтах длины для строк и разделителей.
Но для реляционного моделирования нет никаких сомнений. Правильное решение - отдельные столбцы или даже отдельные строки в таблице ассоциаций.
explode()
для строк с разделителями, чтобы превратить их вArray
вPHP
, не сохраняя их какstring
, если это проблема, но дляFirst Scheme
я просто помещаю их непосредственно вArray
без необходимости их создания строки с разделителями .