#php #mysql
#php #mysql
Вопрос:
Я не уверен, как это правильно сформулировать, но позвольте мне попробовать. Я работаю над созданием приложения для управления запасами, которое будет использоваться со многими разными клиентами, чтобы делать все, начиная с проверки их собственного запаса товаров, получения цен, заказа товара и т.д. Интерфейс выполнен на Flex (Flash Builder), а серверная часть — MySQL и PHP. Итак, вот реальный вопрос, я думаю. Когда клиент размещает заказ на продукт, я не уверен, сколько из того, что он заказывает, но мне нужно сохранить все товары в один «билет». (Пример: один заказ может быть на 2 яблока, 3 апельсина, банан и киви — следующий может просто заказать одно яблоко.) Итак, в моей базе данных tickets у меня есть место для 20 элементов (ticketItem1, ticketItem2 и т. Д.) — Очевидным недостатком здесь является то, что если клиент заказывает только один продукт, у меня остается 19 пустых мест.
Какие типы проблем, если таковые имеются, обычно связаны с наличием большого количества нулевых значений в базе данных? Есть ли способ предотвратить их возникновение? И есть ли какие-либо предложения, чтобы помочь в этом?
Также и, наконец, — каждый заказанный элемент (давайте снова используем apple) имеет свой собственный УНИКАЛЬНЫЙ штрих-код, связанный с ним. Таким образом, одно яблоко может быть пронумеровано 0001, а другое может быть 4524…
Спасибо за любую помощь, которую вы можете предложить.
-CS
Комментарии:
1. Почему вы не можете использовать отношение 1: n для хранения заказов и заказанных товаров?
2. Прочитайте о нормализации базы данных.
3. Вы не должны делать это таким образом. Вы должны добавить еще одну таблицу с именем
orderItemsили что-то в этом роде, с идентификатором заказа в нем — таким образом, вы можете иметь бесконечное количество продуктов на заказ, это намного проще в управлении, и это шикарное отношение «один ко многим».
Ответ №1:
Вместо 20 столбцов ticketItem1, ticketItem2, ... введите таблицу order_item , например:
Порядок таблиц:
id customer
1 42
2 23
Элемент таблицы:
id name
1 banana
2 kiwi
3 apple
4 oranges
Table order_item:
order_id item_id multiplicity
1 1 1 # 1 banana
1 2 1 # 1 kiwi
1 3 2 # 2 apples
1 4 3 # 3 oranges
2 3 1 # 1 apple in the second order
Затем СОЕДИНИТЕ таблицы, чтобы получить все упорядоченные элементы в порядке.
Ответ №2:
У вас должна быть таблица, в которой указан порядок, и таблица для OrderDetails с идентификатором OrderID, указывающим на таблицу Order
Итак, если у вас есть 10 продуктов в заказе. У вас будет 1 строка по порядку и 10 в OrderDetails
Комментарии:
1. Итак, если я правильно понимаю, у меня все равно будет много нулевых значений, они просто будут в отдельной таблице, которая определяет, какой конкретный продукт был запрошен для этого «билета». В чем преимущество этого способа по сравнению с другим? — Я также прочитаю больше о нормализации БД. Однако — будет ~ 30-50 заказов / билетов в день… Я ценю помощь!
2. Не совсем. У вас есть 1 таблица, в которой перечислены все заказы, без билетов. Например, в этой таблице у вас есть следующие столбцы: ID, OrderDate, IsProcessed, а в другой таблице OrderItems: ID, OrderID, Ticket и любые другие столбцы для конкретной информации для 1 билета. Если у вас есть один заказ с 20 билетами. У вас будет 1 запись в таблице Orders и 20 записей в OrderDetails. И ни в каких столбцах не будет нулевых значений
Ответ №3:
Если вы хотите быть динамичным в том, что вы храните, вы можете использовать массив json. Я полностью согласен с другими, что нормализация базы данных — это первое, что нужно сделать. Я бы следовал правилам Кодда.
Но в случае, если вы не знаете точно, что вам нужно для хранения, json может быть решением. Однако одним из основных недостатков является то, что поиск становится довольно сложным.