Форум по Delphi программированию

Delphi Sources



Вернуться   Форум по Delphi программированию > Все о Delphi > Базы данных
Ник
Пароль
Регистрация <<         Правила форума         >> FAQ Пользователи Календарь Поиск Сообщения за сегодня Все разделы прочитаны

Ответ
 
Опции темы Поиск в этой теме Опции просмотра
  #1  
Старый 08.08.2008, 10:35
Dj_Touch Dj_Touch вне форума
Прохожий
 
Регистрация: 07.08.2008
Сообщения: 3
Репутация: 10
Лампочка Вопрос по работе SQL с базой данных

БД предназначена для подбора клиентам ближайших подрядчиков для выполнения строительных работ. В каждой записи будет несколько полей "рабочей информации", т.е. те данные, которые имеют значение для деятельности самой фирмы: Дата поступления заявки, источник информации, сотрудник принявший информацию, сотрудник, непосредственно работающий с конкретным клиентом. Кроме того будут "контактные данные" ( ну тут я думаю очевидно какие поля :-) ) и поля заявки. Видов строительных/ремонтных работ достаточно много, поэтому у меня возникает идея Организовать эти данные булевыми переменными, т.е. всего 2 варианта - выполняет подрядчик конкртеный вид работ или нет. Третьего не дано.
И так :-) Первый мой вопрос:
Будет ли оправданным вести основную базу, которая будет состоять всего из 6-и Полей: Ключ, ID_клиента (Будет связана с базой клиентов, куда будут входить эти самые "Контактные данные"), Рабочая_инфо (Будет связана с базой, куда вносится вся "Рабочая информация"), ID_заявки (Соответственно будет связана с базой заявок, где будет храниться огромное кол-во булевых переменных), поле состояния (активен/занят ), и скажем так поле истории?
Идея заключается в том, что Вся эта информация относится к одному единственному контакту, НО скажем для подбора заказчиков подрядчикам нужна информация только о заявках, и тогда мы будем проводить запросы с использованием основной таблицы, и таблицы заявок. Для поиска в базе данных конкретного клиента по ФИО, Адресу или телефону, мы будем использовать базу клиентов, ну и таким же образом будет проходить анализ "рабочей инфо". Вместо грузной базы данных получается несколько маленьких.

Какие подводные камни могут быть? Мне неясным представляется следующая ситуация ( для простоты понимания будем считать, что в основной базе, содержащей лишь ID-шники будет еще и поле дислокации подрядчика ) : Нам нужно найти всех подрядчиков, Работающих в городе N, и выполняющих услугу X. Поэтому нам нужно выполнить запрос по базе заявок с конструкцией типа ‘SELECT ID_Услуги FROM Услуги WHERE Услуга_X = true’, откуда мы получим ID всех подрядчиков, выполняющих определенную услугу. Еще одним шагом будет поиск среди контактов тех подрядчиков, которые живут в городе N. ‘SELECT ID_клиента FROM ГлавнаяБаза WHERE (Дислокация = Город N) AND ( ID_Услуги = [Предыдущий запрос]). Понятно, что на этом шаге мы определились с идентификаторами всех подходящих нам подрядчиков. Но далее нам нужно вывести Инфо клиента. Хорошо, массив ID_клиентов у нас уже есть, осталось вывести необходимые поля. Опять обращаемся уже к 3-ей базе – базе клиентов.
В действительности ли работа с этими 3-мя базами произойдет быстрее, чем работа с одной большой? А если в запрос придется включить еще и дату поступления заявки, или скажем источник откуда эта информация поступила (чтобы отсеять ненадежные источники, и включать их в поиск только по необходимости)? Я понимаю, что моим вопросы могут показаться наивными. Если подумать логически, то все эти выкрутасы оправданны и поиск действительно будет организован гораздо быстрее, нежели в случае, с одной «грузной» базой. Но это моя первая серьезная работа с базами данных, и не хотелось бы совершать чужих ошибок. Если я в чем-то не прав прошу меня поправить :-).
Надеюсь, мое описание базы не было излишним, теперь вторую проблему будет описать гораздо проще. И так, все эти заявки, о которых так много говорилось можно логически поделить на категории: Потенциальные клиенты, необработанные или новые заявки (Т.е. в базу данных поступили, но ни один сотрудник за подбор заявок еще не взялся), свободные, выполняемые заказы, удовлетворенные заявки. Все эти категории легко загнать в новое поле «Статус», и в каждом запросе указывать статус необходимой заявки. Скажем нам необходимо выбрать только среди свободных заявок, так зачем в поиск включать всех, в том числе и тех, кто уже давно удовлетворен :-). НО, постоянно указывать статус заявки – это конечно же прикольно, и заявку из одной категории в другую удобно кидать… НО, все-таки производить поиск по 5000 контактов из категории «Свободные» гораздо быстрее, чем из 25000, во всей базе. Что я имею в виду? У меня возникает идея раскинуть каждую категорию заявок в свою отдельную таблицу. Как мне представляется соединять таблицы средствами SQL - не представляет особого труда. А вот что меня действительно интересует так это дрейф данных из одной категории в другую. Не будет ли накладным постоянное удаление/добавление записей? Не будет ли проблем с уникальными ключами? Если кто сталкивался с подобными задачами, или просто имеет какие-то мысли по этому поводу прошу ответить :-).
Ответить с цитированием
  #2  
Старый 08.08.2008, 11:39
Аватар для Aristarh Dark
Aristarh Dark Aristarh Dark вне форума
Модератор
 
Регистрация: 07.10.2005
Адрес: Москва
Сообщения: 2,906
Версия Delphi: Delphi XE
Репутация: выкл
По умолчанию

Первый вопрос больше по структуре базы, по нему без четкого видения задачи я ничего комментировать не буду ибо знаю, что любой комментарий в данном случае будет ошибочным.
По второму вопросу. Нельзя ни в коем случае делить однотипные данные по разным таблицам. Сам же и запутаешься. Таблица "Заказы" будет не такой уж и большой, и сделать в ней выборку/сортировку по статусу заказа будет не сложно
__________________
Некоторые программисты настолько ленивы, что сразу пишут рабочий код.

Если вас наказали ни за что - радуйтесь: вы ни в чем не виноваты.
Ответить с цитированием
  #3  
Старый 08.08.2008, 11:52
Phedor Phedor вне форума
Начинающий
 
Регистрация: 28.02.2008
Сообщения: 118
Репутация: 21
По умолчанию

0. По структуре не совсем верно. Лучше не булевые делать, потому как избыточность получается, лучше делать связку Id, Id_Клиента, Id_Работы. Если в таблице нет, значит и не выполняет, если есть, значит делает :-)
1. Не проще сделать примерно так:
Таблица Customers - заказчики, со всеми реквизитами
Works - таблица-справочник возможных работ
CustomerWorks - таблица связки (id, Customer_Id, Works_Id)
Flows - заявки (id, Customer_Id, FlowFrom, FlowTo ...), где FlowFrom, FlowTo с какого по какое заняты.
Все остальное делается с помощью запросов
2. Постоянное добавление/удаление не есть гуд. Потому как физически записи не удаляются, а помечаются, поэтому у вас база будет распухать и переодически нужно будет производить упаковку. Не нужно бояться "длинных" таблиц. Главное нормально настроить индексы.
Ответить с цитированием
  #4  
Старый 08.08.2008, 15:20
Dj_Touch Dj_Touch вне форума
Прохожий
 
Регистрация: 07.08.2008
Сообщения: 3
Репутация: 10
По умолчанию

Цитата:
Сообщение от Aristarh Dark
Первый вопрос больше по структуре базы, по нему без четкого видения задачи я ничего комментировать не буду ибо знаю, что любой комментарий в данном случае будет ошибочным.
Вопрос не совсем о структуре. Вопрос в том, оправдано ли выделять сущности, относящиеся к отдельной группе (например контактные данные), в отдельную таблицу? Собственно во всех проектах, которые я видел так и происходит. Но мне хочется понять почему это так. Хотя я читал информацию о языке SQL, все же не совсем понимаю основной принцип его работы. При запросе к таблице по N полям из M в память подгружаются абсолютно все поля, и только уже результатом будут необходимые нам N полей? Если это мое предположение верно, то вопрос снимается. И кстати, где можно задавать вопросы по структуре базы (если на этом форуме можно). Просто не нашел соответсвующего раздела, извините :-)

Цитата:
Сообщение от Aristarh Dark
По второму вопросу. Нельзя ни в коем случае делить однотипные данные по разным таблицам. Сам же и запутаешься. Таблица "Заказы" будет не такой уж и большой, и сделать в ней выборку/сортировку по статусу заказа будет не сложно
Прежде чем увидел твой ответ тоже поразмыслил хорошенько, и встерил серьезные трудности, мешающие воплощению этого замысла. Стало понятно, что делить однотипные данные по разным таблицам не рационально. Теперь вопрос в другом: Допустим у меня таблица с сотней полей, и одно поле Статус, которое имеет 6 значений. Мне необходимо отыскать запись (записи) в которых, к примеру Статус=1, и существует еще какое-то условие. Имеется ли механизм, благодаря которому можно отсеить 5/6 таблицы (без значит затратов ресурсов памяти), оставив только записи со статусом=1, а уже из этой части таблицы выполнять сложные запросы?
Ответить с цитированием
  #5  
Старый 08.08.2008, 15:28
Dj_Touch Dj_Touch вне форума
Прохожий
 
Регистрация: 07.08.2008
Сообщения: 3
Репутация: 10
Радость

Phedor, Спасибо за советы, натолкнул меня на соответсвующие мысли. Ранее предпологал сделать поле активен/занят, но действительно сбрасывать со счетов подрядчиков, которые завершат выполнение работ завтра-через пару дней тоже нельзя.
На счет булевых функций пока не берусь рассуждать, так как еще слишком мало данных. В любом случае спасибо за помощь :-)
Ответить с цитированием
Ответ


Delphi Sources

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB-коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход


Часовой пояс GMT +3, время: 19:53.


 

Сайт

Форум

FAQ

RSS лента

Прочее

 

Copyright © Форум "Delphi Sources" by BrokenByte Software, 2004-2023

ВКонтакте   Facebook   Twitter