Вопрос по работе Sql с базой данных

Тема в разделе "SQL", создана пользователем DjTouch, 8 авг 2008.

  1. DjTouch

    DjTouch New Member

    Регистрация:
    8 авг 2008
    Сообщения:
    1
    Симпатии:
    0
    БД предназначена для подбора клиентам ближайших подрядчиков для выполнения строительных работ. В каждой записи будет несколько полей "рабочей информации", т.е. те данные, которые имеют значение для деятельности самой фирмы: Дата поступления заявки, источник информации, сотрудник принявший информацию, сотрудник, непосредственно работающий с конкретным клиентом. Кроме того будут "контактные данные" ( ну тут я думаю очевидно какие поля :) ) и поля заявки. Видов строительных/ремонтных работ достаточно много, поэтому у меня возникает идея Организовать эти данные булевыми переменными, т.е. всего 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. Glucklich

    Glucklich Гость

    Почитайте для начала что есть БД, реляционные БД, СУБД, таблица, поле, кортеж и тд.
    Вам нужно выделить основные сущности. Я выделил несколько: Заказчик, Клиент, Заявка, Услуга. Каждая сущность в реляционной БД представляет собой таблицу. Далее связывайте эти сущности между собой. Например, для связи сущности Услуга и Заказчик необходима дополнительная таблица (УслугаЗаказчик - отношение многие ко многим).
    Ужас!!! Не в коем случае. Все в одну таблицу + поле Статус.
     
Загрузка...
Похожие Темы - Вопрос по работе
  1. Eugen
    Ответов:
    9
    Просмотров:
    2.267
  2. tumanovalex
    Ответов:
    1
    Просмотров:
    1.591
  3. vladis222
    Ответов:
    1
    Просмотров:
    1.303
  4. ApplePen
    Ответов:
    0
    Просмотров:
    56
  5. gURaBA_N
    Ответов:
    3
    Просмотров:
    91

Поделиться этой страницей