связанные таблицы

← →
MORA (2004-07-27 12:08) [0]

у меня есть 3 связанные таблицы: ЗАКАЗЧИКИ, --> ОБЪЕКТЫ, --> ПОМЕЩЕНИЯ (каждая последующая является подчиненной для предыдущей). И четвертая таблица - ЗАКАЗЫ, в которой хранятся заказы для ПОМЕЩЕНИЙ. Понятно, что по ПОМЕЩЕНИЮ можно идентифицировать ОБЪЕКТ, по ОБЪЕКТу - ЗАКАЗЧИКа, поэтому в заказах я храню только ПОМЕЩЕНИЕ.
Вопрос в следующем:
как по-умному заполнить ДБэдиты при открытии формы редактирования заказа (чтобы в зависимости от ПОМЕЩЕНИЯ заполнились ОБЪЕКТЫ и ЗАКАЗЧИКИ)?
Проблемка в том, что таблицы связаны и с помощью DataSet.Locate() сделать это низя.

← →
Johnmen © (2004-07-27 12:12) [1]

Они сами "заполняются"

← →
Соловьев © (2004-07-27 12:13) [2]

> Проблемка в том, что таблицы связаны

как связаны?

← →
DSKalugin © (2004-07-27 12:17) [3]

значит надо именить порядок подчиненности
ПОМЕЩЕНИЯ --> ОБЪЕКТЫ --> ЗАКАЗЧИКИ
Читай подробно про связь между таблицами master/detail
а конкретней свойства
TDataSet.MasterSource
TDataSet.MasterFields

← →
MORA (2004-07-27 12:19) [4]

> как связаны

с пом. св-ва MasterSource

> Они сами "заполняются"

тогда как правильно заполнить св-ва ДБэдитов?

← →
DSKalugin © (2004-07-27 12:53) [5]

есть еще такие компоненты как TDBComboBox
это к вопросу о заполнении

← →
Sergey13 © (2004-07-27 13:19) [6]

2MORA
А твой FlashFiler позволяет использовать SQL?

← →
bushmen © (2004-07-27 13:20) [7]

> MORA (27.07.04 12:08)

TDBCombobox тебе поможет

← →
bushmen © (2004-07-27 13:21) [8]

> Sergey13 © (27.07.04 13:19) [6]

Да, похоже своим FlashFilter автор всех уже основательно доканал :)

← →
MORA (2004-07-27 13:45) [9]

> TDBCombobox тебе поможет

я использую RXDBComboEdit

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

← →
Sergey13 © (2004-07-27 14:12) [10]

2MORA (27.07.04 13:45) [9]
>что-то само ну никак не хочет заполняться
Да что ты? Ну надо же? Свинство какое то! 8-)
Про SQL ответь. Можно?

← →
MORA (2004-07-27 14:18) [11]

> Про SQL ответь. Можно?
угу

← →
Sergey13 © (2004-07-27 14:21) [12]

Ну дык и напиши запрос который вернет тебе все нужные реквизиты.

← →
MORA (2004-07-27 14:24) [13]

> Sergey13 ©

дык хочется с табл. разобраться

← →
Sergey13 © (2004-07-27 14:28) [14]

2MORA (27.07.04 14:24) [13]
Ну разбирайся. Надоест - скажешь.

← →
bushmen © (2004-07-27 14:32) [15]

> MORA (27.07.04 14:24) [13]

Ты хочешь, чтобы мы за тебя все написали, а ты только код скопировал? :)

← →
MORA (2004-07-27 14:33) [16]

> Sergey13 © (27.07.04 14:28) [14]

добрейшей души чел.

← →
MORA (2004-07-27 14:36) [17]

> bushmen © (27.07.04 14:32) [15]
> > MORA (27.07.04 14:24) [13]
>
> Ты хочешь, чтобы мы за тебя все написали, а ты только код
> скопировал? :)

если бы хотел, я бы кинул вам (Вам) свой код и предложил бы разбираться в нём.
а я задал простой вопрос ТЕОРЕТИЧЕСКИЙ с надеждой на то, что кто-то ткнёт пальцем куа копать...

← →
Sergey13 © (2004-07-27 14:53) [18]

2MORA (27.07.04 14:36) [17]
>а я задал простой вопрос ТЕОРЕТИЧЕСКИЙ
Вопрос то простой, но... объемный. 8-)

>кто-то ткнёт пальцем куа копать...
Пальцев не хватит, да и ногти уже в крови от тыканья... 8-)
К тому же такая экзотика как некий FlashFiler - фиг знает чего советовать.

← →
bushmen © (2004-07-27 15:01) [19]

> я задал простой вопрос ТЕОРЕТИЧЕСКИЙ с надеждой на то, что кто-
> то ткнёт пальцем

Вас уже ткнули туда, где копать: в каждой таблице связь "один к многим" поэтому используя в SQL-запросе выражение WHERE Вы всегда найдете главного при выборе подчиненного. :)

← →
MORA (2004-07-27 15:25) [20]

> поэтому используя в SQL-запросе выражение WHERE Вы всегда
> найдете главного при выборе подчиненного. :)

да я уже начал с таблицами работать, а не с запросами (понимая, что это не круто, но начальство поставило конкретное ТЗ, переубедить не удалось).

Поэтому хотелось бы до конца разобраться именно с ТАБЛИЦАМИ.

А FlashFiler - это не очень то экзотика. Почти такое же как обычный TTable. Все методы те же.

Ну и возвращаясь к сути, сформулирую по-другому, чтобы можно было ответить не объёмно:
я могу делать так:
при открытии формы редактирования заказа в обработчике формы OnShow разрываю все связи мастер-деталь (чтобы можно было осуществить поиск), ищу последовательно начиная с "самой подчиненной", делаю везде БУКМАРКИ (т.к. после связывания таблицы вернуться на первые записи), потом устанавливаю прежние разорванные связи и иду по БУКМАРКАМ начиная с "самой главной".

Но разве нет более цивилизованных методов?

← →
bushmen © (2004-07-27 15:42) [21]

> Но разве нет более цивилизованных методов?

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

← →
bushmen © (2004-07-27 15:44) [22]

> А FlashFiler - это не очень то экзотика. Почти такое же как
> обычный TTable.

FlashFilter - это компанент ? Но тогда какая БД ?

← →
MORA (2004-07-27 15:53) [23]

> FlashFilter - это компанент ?

Нет. Это не компОнент!
Это БД такая. Клиент-сервер.

← →
bushmen © (2004-07-27 15:56) [24]

> Почти такое же как
> обычный TTable.

Тогда как это понять? Как можно компонент сравнивать с СУБД?

← →
dimds (2004-07-27 15:57) [25]

гораздо удобнее хранить всю необходимую информацию в таблице ЗАКАЗЫ т.е. заказчиков и объекты. места эти данные займут (т.к. это только коды )немного. но избавят от многих гемороев в будущем.

← →
MORA (2004-07-27 16:15) [26]

> гораздо удобнее хранить всю необходимую информацию в таблице
> ЗАКАЗЫ т.е. заказчиков и объекты. места эти данные займут
> (т.к. это только коды )немного. но избавят от многих гемороев
> в будущем

так можно вообще одну табл. слепить или 2 и всё в неё пихать.

← →
bushmen © (2004-07-27 16:19) [27]

> всю необходимую информацию в таблице ЗАКАЗЫ т.е. заказчиков и
> объекты. места эти данные займут (т.к. это только коды )
> немного. но избавят от многих гемороев в будущем.

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

← →
Sergey13 © (2004-07-27 16:23) [28]

2MORA (27.07.04 15:25) [20]
>но начальство поставило конкретное ТЗ, переубедить не удалось.
Что у тебя только за начальство. 8-) Работай только с этой БД, только такими компонентами/методами. Оно у тебя код проверяет что ли? Откуда оно узнает, что ты SQL стал пользоваться. Настучит что ли какой супостат. Интересно, а если узнает - премии лишит что ли? 8-)

← →
dimds (2004-07-27 16:25) [29]

> bushmen © (27.07.04 16:19) [27]

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

> Sergey13 © (27.07.04 16:23) [28]

У него начальник, наверное, каждый вечер сверяет его исходники со своей бумажкой. Расхождение в каждую запятую - штраф $5 :)))

> какая рассогласованность? просто будет избыточность данных

При удалении или изменении какого-либо реквизита у Заказчика.

> какой поиск по текстовым поляи?

А отчеты по конкретному заказчику? Это не поиск ?

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

См. предыдущее и делай выводы

> хотя тут конечно все зависит от разработчика - как он считает
> нужным

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

2bushmen © (27.07.04 16:30) [31]
Никакой рассогласованности, просто денормализация. Тоже метод, но не лучший ИМХО. Немного больше места, немного больше производительность. Но я лично на такое иду только когда уж шибко тормозит.

> Никакой рассогласованности

Тогда должен следить за изменениями в справочнике заказчиков и корректно обрабатывать. Оно тебе надо? Я же не говорил, что обязательно рассогласованность будет, но верояность есть.

← →
dimds (2004-07-27 16:42) [34]

ну да если используется таблиц 15 смысл есть.
в противном случае от join-ов крыша съедет

> в противном случае от join-ов крыша съедет

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

← →
dimds (2004-07-27 16:50) [36]

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

2bushmen © (27.07.04 16:42) [33]
>Тогда должен следить за изменениями в справочнике заказчиков и корректно обрабатывать.
Нафига? Если есть таблицы 1-2-3. 2 ссылается на 1, 3 на 2. Почему, если 3 будет (ключом) ссылаться так же на 1 будут какие то проблемы?

>dimds (27.07.04 15:57) [25]
>гораздо удобнее хранить всю необходимую информацию в таблице >ЗАКАЗЫ т.е. заказчиков и объекты.

Где тут справочники?

← →
dimds (2004-07-27 17:06) [39]

какое избирательное чтение))))
> места эти данные займут (т.к. это только коды )...

вроде понятно написано, что храняться только КОДЫ из справочников

> вроде понятно написано, что храняться только КОДЫ из
> справочников

Да, что-то слеповат я стал на старости лет :) Приношу свои извинения. Кстати, автор уже давно смылся:)

связанные таблицы Найти похожие ветки