как правильно организовать многовложенность в бд

[undead92]

Привет всем! пишу программу, в которой следующая иерархия -


клиент > карточка клиента>авто>карточка авто и еще 4-5 вложений .

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

Создать у клиента id, а все остальные вложенности должны просто копировать себе его id?

пишу на delphi+mysql

[Vapaamies]

В данном случае -- никак, поскольку эта вложенность искусственная, поскольку сами данные разнородны и не являются деревом. Нужно создать обычную реляционную БД по учебникам, а вложенность, если так уж хочется, рисовать чисто в интерфейсе.

[undead92]

базу создавать умею, программы подобные писал максимум с 3 уровнями, т.е во всех трех таблицах были id , а потом запросом выводил в грид, все получалось, я думаю, может есть какой более удобный способ?

иметтся ввиду что у меня есть dbgrid, двойной клик по записи > еще грид, в котором данные только по этой записи, и так далее

[Vapaamies]

Это классическая задача из учебника. Ведь пишется что-то вроде БД автосервиса?

Главное окно программы -- список клиентов (грид), при клике на клиента открывается его карточка -- диалог, где вписаны его ФИО и другие данные, плюс грид с принадлежащими ему машинами (можно на вкладке). При клике на машине, в свою очередь, открывается карточка машины, где вписаны все данные и может быть грид с описанием ремонтов (тоже на вкладке).

Деревом тут и не пахнет.

[Yurk@]

Деревом тут и не пахнет.

как знать, как знать)
Можно и деревом, а можно и в виде обычных внешних связей - цепляясь по id предыдущего уровня.

Создать у клиента id, а все остальные вложенности должны просто копировать себе его id?

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

[Аватар]

Здесь похоже везде отношение один-к-одному. Разве что у клиента несколько машин. Тогда и нет ни какой необходимости данные распылять по нескольким таблицам. Если один-к-многим тогда как Yurk@ предложил

[undead92]

разумеется, у клиента несколько машин, а у каждой машины несколько таблиц, с этим теперь понятно, спасибо))

Сразу хочу еще вопрос задать - как в 1 dbgrid выводить несколько запросов, если его можно только к 1 query привязать?

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


или придется делать столько гридов друг на друге, сколько и запросов, при этом при нажатии на кнопки "только грузовые","только легковые" - скрывать ненужные гриды?

[Yurk@]

или придется делать столько гридов друг на друге ...

нет, просто нужно правильно запрос составить и подключить к тему не одну, а несколько таблиц посредством JOIN и вывести дополнитено поля с этой таблицы. все это будет в одном query - соответственно с ним можно работать как с единым целым.
пример:

SELECT k.id, k.name, a.type, a.nomer 
FROM klient k
  JOIN auto a ON k.id = a.klient_id
WHERE <а вот этим условием уже играться как тебе нужно>

[undead92]

но не совсем понял, запросы то у меня разные,то есть изначально

select * from avto - в grid весь список

если нажимаю кнопку только грузовые, то

select * from avto where tip=gruzovie - и результат выводится в этот же грид.

то есть непонятно что надо прописать на кнопку чтобы в грид выполнялся другой запрос? а если писать в 1 запросе то вообще не понятно как кнопка поймет какой ей sql.add выполнить, а какой пропустить

[Vapaamies]

Сообщение от undead92

как кнопка поймет какой ей sql.add выполнить, а какой пропустить

Кнопка не поймет, она думать не умеет. Понять должен программист.

Если предложение where является последним в запросе, достаточно будет присваивать SQL.Strings[SQL.Strings.Count - 1] нужное значение. Если же запрос простой, достаточно воспользоваться параметрами и менять только значение параметра, оставляя текст запроса неизменным. В учебниках именно этому и учат.

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