Я создаю инструмент для редактирования веб-страниц в CMS. Основная цель инструмента – полная гибкость для пользователя. Поэтому в нем можно редактировать большое количество свойств – такие свойства, как эти (фрагмент):
langbutton_menu_border_color_left langbutton_menu_border_width_left langbutton_menu_border_style_left langbutton_menu_border_color_right … вы получаете дрейф. На сегодняшний день у меня есть 238 таких свойств, в основном целых и коротких строк. Теперь я должен создать таблицу mysql для данных. У меня есть опыт работы с веб-разработками на протяжении нескольких лет, и было абсолютным запретом даже рассматривать возможность размещения 238 столбцов в таблице mySQL. Но, подумав, я начинаю думать, почему бы и нет?
Это самая удобная вещь для меня прямо сейчас, так как моя CMS, в которую я интегрирую этот новый инструмент, имеет набор готовых элементов ввода, которые связаны с отдельными столбцами базы данных. Любой другой способ хранения свойств (например, группировка их, так что свойство «граница» хранится в одном поле) потребовало бы огромных изменений в коллекции, чего я бы очень хотел избежать – у меня большой проект и буквально рабочий день и ночь.
Я бы создал и изменил таблицу на основе определения XML, поэтому я мог бы жить с администрированием таблицы столбцов 238. Эффективность хранения не важна – ожидаемое количество страниц не будет превышать 50-100. Мне нужно делать запросы в таблице, за исключением загрузки одной страницы за один раз с использованием первичного ключа.
Итак, эксперты mySQL, есть ли что-нибудь всерьез против хранения таких данных в 238 столбцах? Будете ли вы ожидать проблем, экспоненциального использования памяти, что-нибудь в этом роде?
Обычно я переводил различные свойства в полные строки CSS и строил классы, которые могли бы анализировать и обрабатывать такие строки, что значительно сократило бы число. Но учитывая временные ограничения?
Теоретически mySQL теперь ограничивается 4096 столбцами в таблице (немного меньше, учитывая другие ограничения, то есть значения по умолчанию NULL и т. Д.). Итак, у вас есть довольно большой запас. Лично в веб-разработчике я пытаюсь сохранить # столбцов <50. Я видел таблицы со 100 + столбцами, и это сработало, но очень сложно поддерживать такие таблицы. Если вам не нужно искать в этих столбцах, рассмотрите сериализацию в php-массиве и сохраните значения в TEXT. Это быстрее и гибче.
Сколько из этих столбцов нужно запрашивать и обновлять независимо от других? Связаны ли какие-либо из этих столбцов с отношениями к другим таблицам, или все они просто данные?
Я не знаю вашего плана использования, но в некоторых случаях имеет смысл хранить все эти данные в виде BLOB. Это то, что я буду делать, если он всегда будет удален вместе и не будет участвовать в каких-либо запросах.
Раньше я пробовал такой подход. Скорее всего, никто никогда не будет использовать все 238 свойств на одном элементе.
ИМХО, вам было бы лучше предлагать доступные свойства пользователю. Затем позвольте пользователю объединить доступные свойства, выбирая их из списка и устанавливая их значения. Затем вы можете объединить ввод пользователей в текстовый массив, например [property: value, property: value], и вставить его в один столбец элемента, который вам нужен.