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

[haviras.livejournal.com]

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

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

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

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

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


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

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

Comments

[hcjack.livejournal.com]

Если вы не представляете - может стоит сначала научится этому, и не заниматься теми вещами в которых не разбираетесь?

Вам нужна еще одна таблица в которую будет записываться ID заказа, ID клиента, тип заказа, ну и какая нить сопутствующая информация если нужно (дата/время например).

[haviras.livejournal.com]

Спасибо, я умею писать БД и SQL знаю хорошо. Просто написать надо срочно. А я в связи с праздниками немного не в состоянии мыслить адекватно :)

[hcjack.livejournal.com]

Честно говоря ваши знания у меня вызывают сомнения :)
У меня в книге "PHP для ламеров" подобная схема описана в первых главах :)
Военного тут абсолютно ничего нет.

[haviras.livejournal.com]

Я бухой в жопу. А писать надо.

[hcjack.livejournal.com]

левые отмазки :)
такие вещи у программеров отскакивают от зубов в любом состоянии

[haviras.livejournal.com]

Я сисадмин

[homa.livejournal.com]

Хехе, это верно. Я свой коммент как раз в таком состоянии и писал. И ничего.

[haviras.livejournal.com]

Ну вот докопались. Я не программист же.

[homa.livejournal.com]

С этим мы уже определились. Не секрет, а зачем тогда вы полезли на эти галеры? :)

[haviras.livejournal.com]

Для ведения учета клиентской базы фирмы своей как ни странно.
1С и прочая чехарда не катит, потому что мне реально нужен список клиентских карточек и список заказов (все), и ставить мне ее лениво. Хотя там конечно уже все есть. И все готово. Но я ж не ищу легких путей...

[homa.livejournal.com]

Что ж, с этим мы тоже определились.

Вы неправы.

[haviras.livejournal.com]

В чем?

[homa.livejournal.com]

В отношении к своей фирме и к участникам этого сообщества.

Вы оказываете медвежью услугу своей фирме, пытаясь сделать то, в чем не разбираетесь.

Вы оказываете неуважение участникам сообщества, пытаясь переложить на них работу и ответственность, которую зачем-то взяли на себя.

В общем, оставим эту тему.

[haviras.livejournal.com]

Фирма моя собственная. Личная.
Так что ни на кого ответственность я не перекладывал.
А спросил по причине перепоя и отстуствия в асе людей (запой видать тоже) как связать две таблицы. А тут развели флуд на полсотни постов

[haviras.livejournal.com]

Собсно еще одна из причин - мне нужен доступ к вебинтерфейсу БД. 1С такого не позволяет. Или позволяет?

[guest-o.livejournal.com]

Уже исходя из терминологии: "я умею писать БД" -- возникает ряд сомнений по этому поводу...

[haviras.livejournal.com]

Вот придираются к словам

[haviras.livejournal.com]

Да, спасибо за то что напомнили о связывающей таблице.
Вопрос закрыт

[antropovalexey.livejournal.com]

обожемой

[haviras.livejournal.com]

Они убили Кенни!

[homa.livejournal.com]

Таблица Clients: ID, Name, Address, TotalAmount.
Таблица OrderTypes: ID, Title.
Таблица Orders: ID, ClientID, TypeID, Amount, Date...

В первой таблице хранятся данные по клиентам (сводные).

Во второй — типы заказов.

В третьей — конкретные заказы конкретных клиентов (ClientID) конкретного типа (TypeID). На каждого клиента может в этой третьей таблице иметься произвольное число записей, в чем траблема?

Добавление заказа:

insert into orders (ClientID, TypeID, Amount, Date)
values (10, 9, 500.00, '2007-12-29')

Вот в таком ключе. В данном случае 10 — это некий клиент из таблицы Clients, а 9 — это некий тип заказа. Заказ на сумму $500 зарегистрирован сегодня.

[haviras.livejournal.com]

Пасибо большое. Но меня интересовал вопрос именно связки двух "один-ко-многим"

[homa.livejournal.com]

Таблица Clients и таблица Orders в данном случае и находятся в отношении один ко многим. Каждой записи в таблице Orders соответствует одна запись в таблице Clients, но одной записи в таблице Clients может соответствовать ноль, одна или несколько записей в таблице Orders.

[haviras.livejournal.com]

Уважаю вашу дотошность. Спасибо. Но меня все же интересовал ответ в одну строчку "создай третью таблицу для связи двух других"

[homa.livejournal.com]

Другими словами, вас интересовал дурацкий ответ :) Это не таблица для связи двух других. Судя по всему, это и есть основная таблица вашей базы данных, а две другие - лукап-таблицы, содержащие повторяющиеся и сводные данные.

Re

[granite-golem.livejournal.com]

Самое простое решение - таблица заказов клиентом. Актуальных заказов, не типов. В одном поле - идентификатор заказа (primary key), в другом поле - ID клиента, в третьем - тип заказа.

Re

[granite-golem.livejournal.com]

Ну я и не сомневался, что все подумают так же.

[meanab.livejournal.com]

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

Это очень круто. То есть, вообще, люди, способные написать в одиночку СУБД (http://ru.wikipedia.org/wiki/%D0%A1%D0%A3%D0%91%D0%94) вызывают огромное уважение, но такие попадались. А вот такие, для кого это еще и «не проблема» — это очень-очень круто.

[haviras.livejournal.com]

А вам проблема написать БД в 5 таблиц?

[meanab.livejournal.com]

Не берите в голову, это просто придирка к словам. «Написать СУБД» означает написать нечто из ряда продуктов таких, к примеру, фирм, как Sybase, Oracle и т.д. (если говорить о реляционных СУБД). «Написать БД» — вообще бессмысленное выражение. Можно разработать структуру БД из пяти таблиц, можно написать программу, использующую БД из пяти таблиц.

[haviras.livejournal.com]

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

[meanab.livejournal.com]

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

[haviras.livejournal.com]

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

[meanab.livejournal.com]

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

[haviras.livejournal.com]

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

[meanab.livejournal.com]

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

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

[homa.livejournal.com]

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