#php #sql #mariadb
Вопрос:
Допустим, у меня есть список клиентов с их идентификаторами клиентов и другой информацией, и я хочу добавить несколько клиентов в одну партию/заказ. Таблица заказов будет динамически распространяться на веб-странице с небольшими сводными билетами заказов для каждого заказа, а затем при нажатии на нее будет отображаться дополнительная информация о заказе, включая все идентификаторы клиентов и другую информацию, связанную с ним. Функциональность будет включать добавление и удаление пользователей из определенных заказов и, очевидно, их сохранение для повторного вызова
Я новичок в PHP и SQL, я могу динамически распространять клиентскую таблицу и заказывать билеты, но Google довел меня только до этого.
Лучшее решение, которое я придумал, — это сохранить список идентификаторов пользователей в новой строке таблицы заказов и написать PHP-скрипт для его редактирования. Возможно ли это? Или даже хороший способ сделать это? Любой совет будет очень признателен.
Комментарии:
1. Это возможно, но это плохая идея. Используйте (собственный) дизайн отношений с базой данных.
orders,order_items,clients. Найдите в Google тип отношений, таких как «OneToMany», «ManyToMany». В зависимости от отношения вам понадобится другая таблица. Илиorder_itemтаблице нужен столбецclient_id.2.
he best solution I came up with is to store a list of the users ids in a new row of the order table and write PHP script to edit it. Is this possible…да, но обычно это плохая идея. Вероятно, это похоже на отношения «многие ко многим» между клиентами и заказами. Таким образом, у вас будет таблица Клиентов, таблица Заказов и таблица заказов клиентов, где каждая строка содержит одну уникальную комбинацию идентификатора клиента и идентификатора заказа. Затем вы можете использовать запросы ОБЪЕДИНЕНИЯ для выборки всех связанных клиентов для любого заданного заказа или наоборот.3. В качестве отступления, пожалуйста, потратьте некоторое время на изучение дизайна реляционных баз данных, прежде чем вы продолжите этот проект и попадете в большую запутанную ситуацию. Всегда устанавливайте фундамент, прежде чем пытаться построить здание.
4. P.S. В своем вопросе вы неоднократно меняете терминологию между клиентами / пользователями и заказами / билетами / пакетами. Я думаю , что на самом деле здесь действуют только две сущности (клиенты и заказы), но мешанина необъяснимой терминологии делает это менее чем ясным. Если вы пишете спецификацию и определяете базу данных, она должна быть на 100% кристально ясной, последовательной и однозначной в отношении того, что все это означает и как они связаны, иначе — опять же — вы свяжете себя и всех, с кем вы работаете над этой задачей, в неприятные и запутанные узлы.