Прикольно. Даже бан. И не мне
И правда, старею

_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."

Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar

кстати я тоже в одной таблице храню данные массивом (serialize).
когда собирают заказ там хранятся данные что собрали и сколько.
Массив такой: id из таблицы заказа => количество.
Как пример: array(1=>1, 3=>5,4=>1,5=>2).

Я к чему собственно ?
Это нормально для этого задачи, или лучше было поделить скажем на 2 таблицы ?
В первой номер, и весь "паровоз" (кто, когда, откуда, куда и т.д ). Во второй содержимое (id сборки, id заказа, количество).

или может как по другому ?

Kusss, архитектура БД начинается с определения сущностей и установления связей между ними, на каждую сущность выделяется по таблице + таблица для каждой из связей "многие ко многим"

_____________
Стимулятор ~yoomoney - 41001303250491

Kusss, это у тебя очень упрощенное решение и пойдет для совсем простого магазина.
В общем случае он не решает кучу задач, как то статистика продаж, топовые продажи и т.д.
Вообще сериализ. данные можно хранить в базе, но для вспомогательных данных, динамической различной природы, такие как настройки.

_____________
There never was a struggle in the soul of a good man that was not hard

Invis1ble, не факт что это оптимальнее, но однозначно это крест на работе с конфигом на уровне СУРБД


_____________
Стимулятор ~yoomoney - 41001303250491

Valick
в моём случае оптимальнее, иначе не стал бы так делать. Мне не нужны какие-то связи, группировки или еще что-то. Просто хранилище, под которое уже есть готовый интерфейс в системе. Можно было бы конечно заюзать какую-нибудь монгу к примеру, но ради одной таблички с конфигом разрабатывать отдельное API и заниматься установкой/настройкой ПО не хочется.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Michael
Дело в том, что мне по этим сборкам не нужна никакая статистика.
это формирование товарной накладной. И принять её в пункте назначения. ну и отменить в случае необходимости.
ещё есть объединение/удаление нескольких. Редактирования нету.