Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Длинная цепочка связей.. 
:(
    Опции темы
JenHak
Дата 5.6.2014, 15:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 5
Регистрация: 23.2.2014

Репутация: нет
Всего: нет



Здравствуйте, хотелось бы узнать как лучше составить sql запрос. 
Есть таблицы справочники, промежуточные таблицы и несколько функциональных. 
В итоге для получения справочных данных для конечной таблицы приходится пройти через 3-4 другие..
Выходит не очень красиво и трудно читаемо.  
Используется Access 2007, связи настроены(1 ко многим), нет ли спец решения? 
прописывать по 5-6 условий в 1м запросе кажется не очень эффективным, 
цепочка из join боюсь потребует слишком много памяти (таблицы от 20 до 1000 записей)

Это сообщение отредактировал(а) JenHak - 5.6.2014, 15:30
PM MAIL   Вверх
PointerToNil
Дата 6.6.2014, 04:27 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата



*


Профиль
Группа: Участник
Сообщений: 108
Регистрация: 17.6.2013

Репутация: 1
Всего: 6



> нет ли спец решения? 
спецрешение называется денормализация: в "основную" таблицу запихивают все "справочные" данные (как вариант - справочная таблица остается как есть и используется при выборе значения в соотв. поле/колонке)
Выходит ну совсем не красиво, зато быстрее работает

> цепочка из join боюсь потребует слишком много памяти (таблицы от 20 до 1000 записей)
а вы не бойтесь, а просто проверьте
как правило, сначала делают нормализацию по максимуму, а уж потом оптимизируют по скорости узкие в плане быстродействия места
память по нынешним временам не проблема, главное, чтобы не тормозило (проблема join в тормозах)
20 - 1000 записей - это курам на смех: вся ваша БД наверняка влезает в оперативную память несколько раз
но если это учебное задание - его следует делать как если бы сложность была в 10 раз больше, а данных больше в 1000 раз

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


Это сообщение отредактировал(а) PointerToNil - 6.6.2014, 06:50
PM MAIL   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Delphi: Базы данных и репортинг"
Vit
Петрович

Запрещено:

1. Публиковать ссылки на вскрытые компоненты

2. Обсуждать взлом компонентов и делиться вскрытыми компонентами


Обязательно указание:

1. Базы данных (Paradox, Oracle и т.п.)

2. Способа доступа (ADO, BDE и т.д.)


  • Литературу по Дельфи обсуждаем здесь
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Вопросы по реализации алгоритмов рассматриваются здесь
  • 90% ответов на свои вопросы можно найти в DRKB (Delphi Russian Knowledge Base) - крупнейшем в рунете сборнике материалов по Дельфи
  • Вопросы по SQL и вопросы по базам данных не связанные с Дельфи задавать здесь

FAQ раздела лежит здесь!


Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Vit, Петрович.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Delphi: Базы данных и репортинг | Следующая тема »


 




[ Время генерации скрипта: 0.0573 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.