Здравствуйте уважаемые товарищи!
Есть много довольно длинных вопросов, которые я постараюсь правильно спрашивать, что бы упростить жизнь и себе и Вам.
И так. Вопрос по организации БД.
- Есть заказ, в который по мере надобности будут включаться всякие операции по обработке этого заказа.
- В каждом заказе может быть несклько изделий.
- Каждое изделие может состаять из нескольких составляющих, имеющие как схожые, так и различные оперции.
- У каждой операции имеются схожие и различные параметры и характеристики.
Я вот думаю, как удобнее организовать БД, что бы было четко понятно и ясно, что к чему.
Делял я так:
Таблица "все заказы".
заказ1 | дата составления | дата сдачи | операция1 | параметр1_операции1 | параметр2_операции1 ... | параметрN_операции1 | операция2 | параметр1_операции2 | параметр2_операции2 ... | параметрN_операции2
и так далее.
Можно ли создавать под каздый заказ отдельную таблицу. Тогда без особого напряга можно будет работать имеенно с теми параметрами, которые реально нужно для заказа?
Спасибо!
_____________
Полная Версия: Организация системы
Я бы тебе посоветовал такую конструкцию не делать -
| Цитата (ApuktaChehov @ 5.11.2009 - 12:01) |
| заказ1 | дата составления | дата сдачи | операция1 | параметр1_операции1 | параметр2_операции1 ... | параметрN_операции1 | операция2 | параметр1_операции2 | параметр2_операции2 ... | параметрN_операции2 |
ведь если тебе или кому то другому придется увеличить количество параметров_операций, то придется в ручную все это дело добавлять, да и на верняка еще и в коде придется править что то.
Предлагаю свой вариант организации базы (схематичный)
- делаешь свою таблицу вида (main):
id заказ | дата составления | дата сдачи | pid операции|
- делаешь другую таблицу где хранятся нужные операции вида (oper):
id операции| pid операции| название| описания|
и тебе остается делать запрос вида:
| SQL |
| SELECT `main`.`дата составления`, `main`.`дата сдачи`, `oper`.`название` FROM `main` INNER JOIN `main`.`pid операции` = `oper`.`pid операции` |
Если я не правильно тебя понял то значит - извиняй.
Хорошая идея, спасибо большое 
Тогда и для операций можно будет организовать такой же подход.
Благодраю!
Таким образом получается, у нас есть заказ, для которого указаны, к примеру через запятую, pid - ы операций. Таким образом мы можем описать заказ с точки зрения составляющих его операций. Далее пойдя таким же путем, можно описать сами операции.
Гениально!
Сейчас буду думать, как орагнизовать такой подход для хранения информации. Ведь у каждого заказа может быть переменное число операций. И записи соответственно будут разные.
Думаю...
Пожалуйста подождите...
_____________
Тогда и для операций можно будет организовать такой же подход.
Благодраю!
Таким образом получается, у нас есть заказ, для которого указаны, к примеру через запятую, pid - ы операций. Таким образом мы можем описать заказ с точки зрения составляющих его операций. Далее пойдя таким же путем, можно описать сами операции.
Гениально!
Сейчас буду думать, как орагнизовать такой подход для хранения информации. Ведь у каждого заказа может быть переменное число операций. И записи соответственно будут разные.
Думаю...
Пожалуйста подождите...
_____________
Это кажись отношение "многие ко многим"
_____________
Бывает, ты ешь медведя, а бывает, что медведь ест тебя (с)
Свернутый текст
- делаешь свою таблицу вида (main):
id заказ | дата составления | дата сдачи
- делаешь другую таблицу где хранятся нужные операции вида (oper):
id операции| название| описания
- делаешь сводную таблицу(oper_in_main)
id заказ | id операции
Аналогично с параметрами будет таблица с двумя полями
id операции | id параметра
id заказ | дата составления | дата сдачи
- делаешь другую таблицу где хранятся нужные операции вида (oper):
id операции| название| описания
- делаешь сводную таблицу(oper_in_main)
id заказ | id операции
Аналогично с параметрами будет таблица с двумя полями
id операции | id параметра
_____________
Бывает, ты ешь медведя, а бывает, что медведь ест тебя (с)
Здесь расположена полная версия этой страницы.