Проектировка БД

[haviras.livejournal.com]

Вопрос опять наверное не по адресу.

Но вобщем у меня такая ситуация:

Надо написать СУБД. С этим проблем нету как бы.
Я не могу представить как хранить клиентские заказы.

Имею таблицу клиенты (имя, адрес, глобальная сумма заказа и прочее)
Имею таблицу типы заказов (список возможных услуг)

Не могу придумать в своей светлой голове такую вещь, как возможность нескольких заказов одним клиентом. Как мне эту вещь хранить и как это на SQL записать (синтаксис) .


БД -MySQL
Вебсервер: Apache
Язык субд: php

UPD: вопрос закрыт. Йа креведко

Comments

[haviras.livejournal.com]

Если честно - первый раз слышу. Все мои знакомые ПРОГРАММИСТЫ БД именно говорят НАПИСАТЬ. Вполне, возможно, что это обсуловлено местным диалектом, но учту терминологию. Спасибо

[meanab.livejournal.com]

А что именно они подразумевают, когда так говорят?

[haviras.livejournal.com]

Проектирование БД и привязка ее к гую.

[meanab.livejournal.com]

Ага, понятно, спасибо.

[haviras.livejournal.com]

Я все же неправ?

[meanab.livejournal.com]

Все же, наверное не стоит так говорить. Так, как вы написали в пояснении — намного лучше, хотя тоже есть нюансы. Так, от выражения «привязка к гую» у меня создается впечатление, что «гуй» уже существует, и нужно только написать слой, который будет заниматься сохранением/восстановлением из реляционной базы, возможно, этакий небольшой object-relational mapper.

Но никогда — умоляю! — не используйте выражение «написать СУБД». У этого выражения есть только один смысл, тот, который подразумевает вопросы типа «реляционную, объектную или что-то более экзотическое?»

[homa.livejournal.com]

Именно проектирование. Замечание по поводу выбора термина было пустяковым, конечно, но вполне справедливым. А насчет привязки к гую (господи, ну и выражение!), так это как раз совершенно другая задача, никаким местом к формату данных и структуре базы отношения не имеющая. Можно более-менее механически создать интерфейс, следуя структуре базы. Можно более-менее механически повторить логику интерфейса в структуре базы. А можно и вообще их независимо создавать, хотя при этом система получится нелогичной и потенциально проблемной. Лучше всего продумывать структурную и интерфейсную составляющую системы заранее, в целом, комплексно.