|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
|
Опции темы | Поиск в этой теме | Опции просмотра |
#1
|
|||
|
|||
Вопрос по работе 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
|
||||
|
||||
Первый вопрос больше по структуре базы, по нему без четкого видения задачи я ничего комментировать не буду ибо знаю, что любой комментарий в данном случае будет ошибочным.
По второму вопросу. Нельзя ни в коем случае делить однотипные данные по разным таблицам. Сам же и запутаешься. Таблица "Заказы" будет не такой уж и большой, и сделать в ней выборку/сортировку по статусу заказа будет не сложно Некоторые программисты настолько ленивы, что сразу пишут рабочий код. Если вас наказали ни за что - радуйтесь: вы ни в чем не виноваты. |
#3
|
|||
|
|||
0. По структуре не совсем верно. Лучше не булевые делать, потому как избыточность получается, лучше делать связку Id, Id_Клиента, Id_Работы. Если в таблице нет, значит и не выполняет, если есть, значит делает :-)
1. Не проще сделать примерно так: Таблица Customers - заказчики, со всеми реквизитами Works - таблица-справочник возможных работ CustomerWorks - таблица связки (id, Customer_Id, Works_Id) Flows - заявки (id, Customer_Id, FlowFrom, FlowTo ...), где FlowFrom, FlowTo с какого по какое заняты. Все остальное делается с помощью запросов 2. Постоянное добавление/удаление не есть гуд. Потому как физически записи не удаляются, а помечаются, поэтому у вас база будет распухать и переодически нужно будет производить упаковку. Не нужно бояться "длинных" таблиц. Главное нормально настроить индексы. |
#4
|
|||
|
|||
Цитата:
Цитата:
|
#5
|
|||
|
|||
Phedor, Спасибо за советы, натолкнул меня на соответсвующие мысли. Ранее предпологал сделать поле активен/занят, но действительно сбрасывать со счетов подрядчиков, которые завершат выполнение работ завтра-через пару дней тоже нельзя.
На счет булевых функций пока не берусь рассуждать, так как еще слишком мало данных. В любом случае спасибо за помощь :-) |