![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
связанные таблицы [D7, FlashFiler]
MORA © (2004-07-27 12:08:00)у меня есть 3 связанные таблицы: ЗАКАЗЧИКИ, --> ОБЪЕКТЫ, --> ПОМЕЩЕНИЯ (каждая последующая является подчиненной для предыдущей). И четвертая таблица - ЗАКАЗЫ, в которой хранятся заказы для ПОМЕЩЕНИЙ. Понятно, что по ПОМЕЩЕНИЮ можно идентифицировать ОБЪЕКТ, по ОБЪЕКТу - ЗАКАЗЧИКа, поэтому в заказах я храню только ПОМЕЩЕНИЕ.
Вопрос в следующем:
как по-умному заполнить ДБэдиты при открытии формы редактирования заказа (чтобы в зависимости от ПОМЕЩЕНИЯ заполнились ОБЪЕКТЫ и ЗАКАЗЧИКИ)?
Проблемка в том, что таблицы связаны и с помощью DataSet.Locate() сделать это низя.
bushmen (2004-07-27 19:58:00) [1]> вроде понятно написано, что храняться только КОДЫ из
> справочников
Да, что-то слеповат я стал на старости лет :) Приношу свои извинения. Кстати, автор уже давно смылся:)
dimds (2004-07-27 17:06:00) [2]какое избирательное чтение))))
> места эти данные займут (т.к. это только коды )...
вроде понятно написано, что храняться только КОДЫ из справочников
bushmen (2004-07-27 16:54:00) [3]>dimds (27.07.04 15:57) [25]
>гораздо удобнее хранить всю необходимую информацию в таблице >ЗАКАЗЫ т.е. заказчиков и объекты.
Где тут справочники?
Sergey13 (2004-07-27 16:51:00) [4]2bushmen © (27.07.04 16:42) [33]
>Тогда должен следить за изменениями в справочнике заказчиков и корректно обрабатывать.
Нафига? Если есть таблицы 1-2-3. 2 ссылается на 1, 3 на 2. Почему, если 3 будет (ключом) ссылаться так же на 1 будут какие то проблемы?
dimds (2004-07-27 16:50:00) [5]чесно говоря не понимаю какие изменения исходников? в какой таблице какие изменения? у тебя есть тот же самый набор справочников, только в таблице, в которой запиываются заказы добавляются коды из справочников. и прописывать-то в одной таблице))
ну автору виднее)))
bushmen (2004-07-27 16:45:00) [6]> в противном случае от join-ов крыша съедет
Крыша съедит, когда при очередном этапе изменения исходников будешь ее ломать в воспоминаниях, в какой бы таблице не забыть еще прописать изменения.
dimds (2004-07-27 16:42:00) [7]ну да если используется таблиц 15 смысл есть.
в противном случае от join-ов крыша съедет
bushmen (2004-07-27 16:42:00) [8]> Никакой рассогласованности
Тогда должен следить за изменениями в справочнике заказчиков и корректно обрабатывать. Оно тебе надо? Я же не говорил, что обязательно рассогласованность будет, но верояность есть.
Sergey13 (2004-07-27 16:35:00) [9]2bushmen © (27.07.04 16:30) [31]
Никакой рассогласованности, просто денормализация. Тоже метод, но не лучший ИМХО. Немного больше места, немного больше производительность. Но я лично на такое иду только когда уж шибко тормозит.
bushmen (2004-07-27 16:30:00) [10]> какая рассогласованность? просто будет избыточность данных
При удалении или изменении какого-либо реквизита у Заказчика.
> какой поиск по текстовым поляи?
А отчеты по конкретному заказчику? Это не поиск ?
> но построение отчетов значительно упростится
См. предыдущее и делай выводы
> хотя тут конечно все зависит от разработчика - как он считает
> нужным
Это зависит не от того как он считает нужным, а от того насколько он уважает себя, а так же тех, кто, возможно, будет это поддерживать после него.
bushmen (2004-07-27 16:26:00) [11]> Sergey13 © (27.07.04 16:23) [28]
У него начальник, наверное, каждый вечер сверяет его исходники со своей бумажкой. Расхождение в каждую запятую - штраф $5 :)))
dimds (2004-07-27 16:25:00) [12]
> bushmen © (27.07.04 16:19) [27]
какая рассогласованность? просто будет избыточность данных. и гимора как раз меньше! какой поиск по текстовым поляи? разумеется все данные вносятся только из справочников. но построение отчетов значительно упростится. чтобы добраться до заказчика нужно перелопатить все таблицы! если коды заказчиков храняться в таблице заказов - намного проще и главное понятнее. хотя тут конечно все зависит от разработчика - как он считает нужным
Sergey13 (2004-07-27 16:23:00) [13]2MORA (27.07.04 15:25) [20]
>но начальство поставило конкретное ТЗ, переубедить не удалось.
Что у тебя только за начальство. 8-) Работай только с этой БД, только такими компонентами/методами. Оно у тебя код проверяет что ли? Откуда оно узнает, что ты SQL стал пользоваться. Настучит что ли какой супостат. Интересно, а если узнает - премии лишит что ли? 8-)
bushmen (2004-07-27 16:19:00) [14]> всю необходимую информацию в таблице ЗАКАЗЫ т.е. заказчиков и
> объекты. места эти данные займут (т.к. это только коды )
> немного. но избавят от многих гемороев в будущем.
Тут я бы поспорил. Места может и немного, а вот гимора в будущем полным полно, потому что придется поиск производить по тектовым полям, да и со временем рассогласованность данных без справочника может наступить. Так что справочник заказчиков обязательно нужен.
MORA (2004-07-27 16:15:00) [15]
> гораздо удобнее хранить всю необходимую информацию в таблице
> ЗАКАЗЫ т.е. заказчиков и объекты. места эти данные займут
> (т.к. это только коды )немного. но избавят от многих гемороев
> в будущем
так можно вообще одну табл. слепить или 2 и всё в неё пихать.
dimds (2004-07-27 15:57:00) [16]гораздо удобнее хранить всю необходимую информацию в таблице ЗАКАЗЫ т.е. заказчиков и объекты. места эти данные займут (т.к. это только коды )немного. но избавят от многих гемороев в будущем.
bushmen (2004-07-27 15:56:00) [17]> Почти такое же как
> обычный TTable.
Тогда как это понять? Как можно компонент сравнивать с СУБД?
MORA (2004-07-27 15:53:00) [18]
> FlashFilter - это компанент ?
Нет. Это не компОнент!
Это БД такая. Клиент-сервер.
bushmen (2004-07-27 15:44:00) [19]> А FlashFiler - это не очень то экзотика. Почти такое же как
> обычный TTable.
FlashFilter - это компанент ? Но тогда какая БД ?
bushmen (2004-07-27 15:42:00) [20]> Но разве нет более цивилизованных методов?
Вам же русским языком сказали, что цивилизованным способом будет использование SQL-запросов. Если хотите извращаться, то пожалуйста без нас