БД предназначена для подбора клиентам ближайших подрядчиков для выполнения строительных работ. В каждой записи будет несколько полей "рабочей информации", т.е. те данные, которые имеют значение для деятельности самой фирмы: Дата поступления заявки, источник информации, сотрудник принявший информацию, сотрудник, непосредственно работающий с конкретным клиентом. Кроме того будут "контактные данные" ( ну тут я думаю очевидно какие поля 
) и поля заявки. Видов строительных/ремонтных работ достаточно много, поэтому у меня возникает идея Организовать эти данные булевыми переменными, т.е. всего 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 варианта - выполняет подрядчик конкртеный вид работ или нет. Третьего не дано.И так
Первый мой вопрос:Будет ли оправданным вести основную базу, которая будет состоять всего из 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 - не представляет особого труда. А вот что меня действительно интересует так это дрейф данных из одной категории в другую. Не будет ли накладным постоянное удаление/добавление записей? Не будет ли проблем с уникальными ключами? Если кто сталкивался с подобными задачами, или просто имеет какие-то мысли по этому поводу прошу ответить .