#php #mysql
#php #mysql
Вопрос:
Я создал форму с более чем 50-100 полями формы (условная форма), и мне нужно сохранить это в базе данных MySQL. Я ищу эффективный способ сохранить эти данные в базе данных MySQL. Насколько я знаю, у меня есть два варианта, я ищу лучший / наиболее эффективный способ.
Вариант 1
Создаем form_submissions таблицу со 100 столбцами и вставляем ее одним запросом.
Вариант 2
Создание key => value таблицы с четырьмя столбцами, например, такими столбцами: id, form_id, key, value , где при отправке каждой формы выполняются запросы 50-100 раз в зависимости от количества заполненных полей.
Рассматривая приведенные выше варианты, вариант 2 определенно кажется лучше, поскольку было бы намного проще сохранить formdata в базе данных, а также не иметь огромной таблицы с (на мой взгляд) слишком большим количеством столбцов.
Комментарии:
1. Да, вариант № 2, вероятно, имеет здесь наибольший смысл. Кроме того, это избавляет вас от необходимости изменять структуру таблицы (и, возможно, запросы также), как только впервые возникает требование к форме с 101 полями 😉
2. @04FS вот что я подумал. Однако не приведет ли выполнение такого количества запросов (форма будет отправляться около 50-100 раз в день) к снижению производительности?
3. 50-100 раз в день — это практически ничего
4. Вы уверены, что вам нужна 1 таблица со 100 полями? Я подозреваю, что некоторые данные могут быть переработаны в таблицах отношений и уменьшить количество полей
5. Смотрите Эту статью , в которой говорится: «Обычно наш сервер базы данных обрабатывает 1000 вставок в секунду. Этого было недостаточно. Итак, я начал искать методы для повышения скорости вставок MySQL и, наконец, смог увеличить это число до 28 000 вставок в секунду.»
Ответ №1:
Ваша ситуация не ясна. По умолчанию используется одна таблица на объект / форму и один столбец на атрибут / поле (вариант 1). У вас должны быть очень веские причины использовать модель EAV (вариант 2). Но в вашем вопросе нет ничего подобного. «100 полей» — это не так уж много. Обратите внимание, что реализация достойного дизайна EAV — это совсем не простая задача. Вам нужно реализовать «схему в схеме», если вы хотите сделать это «правильно». И слишком легко сделать это неправильно. Итак, «поскольку было бы намного проще сохранить formdata в базе данных» — это мечта.
Комментарии:
1. Есть ли у вас какие-либо примеры того, что может пойти не так с моделью EAV? Поскольку это не кажется таким уж сложным в настройке, две таблицы с 7 столбцами в общей сложности — это, по сути, абсолютный минимум для того, чтобы заставить его работать
2. @ArkoElsenaar Две таблицы означают полное отсутствие метаданных. С таким же успехом вы могли бы сохранить данные в текстовом файле. Что при этом может пойти не так?
3. @ArkoElsenaar попробуйте следующий запрос к EAV-таблице:
SELECT * FROM fromdata WHERE field1 = 'x', and field2 = 'y' ORDER BY field3 LIMIT 10 OFFSET 304. Также наиболее распространенные модели EAV хранят все в виде строки, что означает, что вы теряете точность при вычислении с десятичными дробями, также вы не можете обеспечить целостность данных и тип данных, и какие данные нужны приложению для корректной работы, вам нужно написать больше кода приложения или триггеров базы данных, чтобы проверить все это.. @ArkoElsenaar это то, о чем, скорее всего, говорит Пол.. «что может пойти не так с моделью EAV?» Вопрос должен заключаться в том, что может быть правильным при использовании EAV design в RDMS, тогда нам придется меньше печатать