Сообщение от Oscillococcinum
|
Разнесли в пух и прах
|
Это не разнос, это "размышления - для чего база?"
Пусть вы решили в простом блокноте записывать события. Будем считать, что дата события, это его уникальный идентификатор. Если вы будет записывать в блокнот только даты, без описания самого события, сможете ли вы спустя время сказать, что за событие скрывается за каждой датой?
Сообщение от Oscillococcinum
|
передать в БД множественный выбор select
|
Список с множественным выбором, это массив данных под одним ключом (именем списка) на сервере. Код на клиенте к этому вопросу отношения не имеет, и даже можно сказать так - ни в коем случае не должен иметь. if(e.selected) set += '; ' + e.text - это строка на клиенте, показывающая пользователю, что выбрано им, в базу же такое не записывают. А вот как ... тут просто в лоб даже и не ответить.
То что я писал по базе, вроде бы и много написано, но если говорить в целом, то это малая толика и то обобщенная. И списки мной описанные будут выполнять свою роль только в идеальном случае, стоит в базе появится второй категории верхнего уровня и будут ошибки. Но я же не могу описывая только суть вещей писать все. Там описано ради того, чтобы понять - база, это "не склад", это архитектура хранящая в себе данные различных типов, структуры, а также связи между ними. И у вас должна быть такая архитектура базы, чтобы обеспечивать оптимальную работу приложения, то есть, клиент<--->сервер.
Хотите использовать базу, значит имейте базу какой она должна быть, а не "блокнот для пометок". И обязательно найти в сети и прочесть, что такое "нормализация баз данных", так как это понятие тесно связано с вашим вопросом. Если бы ваш вопрос был в рамках практического, имеющейся структуры базы, то можно ответить просто - два способа, в цикле запрос к базе помещаются в нее данные. Но реляционная база данных, которую вы хотите использовать, это сервер, и выполнять запись в нее множеством запросов к ней, это расточительно. А просто набор данных поместить в одну таблицу в SQL можно одним запросом, это она позволяет. Синтаксис такого запроса в упрощенном виде прост:
INSET INTO table_name (field) VALUES (value), (value), (value), ..., (value)
где - field, это имя поля таблицы, в которое производится запись, а value, значения элементов массива. Подготовленное таким образом тело запроса (строка) выполняется запросом к базе, и это будет один запрос к ней. Результатом этого запроса будет N строк записей в таблице.
Массив данных можно хранить в базе и в одном поле как строку представляющую собой JSON. Хотя не так давно MySQL и работает с таким типом данных, не стоит использовать этот тип для данных, например, значения которых используются как параметры выборки и т.п. Так как этим данным требуются предварительные преобразования, а это увеличивается и нагрузку, и время на обработку запроса. Таким набором удобно хранить, например, какие либо параметры конфигурации - запросили, извлекли, преобразовали, используем.
Не зная "контекст окружения" вашего вопроса сложно на него ответить. Здесь может быть только встречный вопрос - а что такое у вас массив данных, его назначение? Например, пользователь выбирает товар на странице, и выбрал несколько, поместив их в корзину. Это множественный выбор? Да. Это массив данных? Да. А как такой массив пишется в базу? Да просто, как выше было написано. Главное тут не механизм записи, а как эти записи хранят в базе.
Товары из корзины превратятся в заказ, а заказ, это покупатель, которые описываются в базе таблицей/набором таблиц. Товары в свою очередь также описаны в своей таблице/наборе таблиц. Заказы также имеют свою таблицу/набор таблиц. Если в таблице заказов писалось бы для покупателя Иванова, купившего халат, тапочки и полотенце:
Заказ №5, покупатель Иванов, адрес ...., тапочки, цена 200, количество 2 штука, итого 400
Заказ №5, покупатель Иванов, адрес ...., халат, цена 1500, количество 1 штука, итого 1500
Заказ №5, покупатель Иванов, адрес ...., полотенце, цена 340, количество 3 штука, итого 1020
это было бы очень расточительно. Поэтому, в таблицу заказов пишется только - его номер как уникальный идентификатор, идентификатор покупателя из таблицы покупателей, дата поступления заказа, статус заказа. С этой таблицей связана таблица товаров заказа, которая содержит номер заказа, идентификатор товара из таблицы товаров, количество товара. Сделав запрос по таблице заказов с вложенными подзапросами к связанным таблицам, можно получить всю информацию о заказе. И это и есть суть "нормализации баз данных".
Что из вышесказанного есть ответ на ваш вопрос? Вот и я не знаю как на него ответить, не понимая что за ним стоит.