![]() |
|
Модераторы: skyboy |
![]()
|
|
| maxim1000 |
|
||||
|
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Участник Сообщений: 3334 Регистрация: 11.1.2003 Где: Киев Репутация: нет Всего: 110 |
когда нам в институте читали курс по БД, нам рассказывали о таком понятии, как роль, это немного похоже на наследование например, сущность "рабочий склада" может служить ролью для сущности "рабочий" при использовании ролей информация общая для всех рабочих (имя, фамилия, дата рождения, ...) хранится в одной "таблице-помойке" если же набор сведений для всех рабочих одинаковый, непонятно, зачем вводить разные таблицы
переносить бизнес-логику на такие вещи, как имена таблиц, IMHO не лучший подход -------------------- qqq |
||||
|
|||||
| Vit |
|
|||
![]() Vitaly Nevzorov ![]() ![]() ![]() ![]() Профиль Группа: Экс. модератор Сообщений: 10964 Регистрация: 25.3.2002 Где: Chicago Репутация: 1 Всего: 207 |
В общем виде такая задача не решается. Зависит от конкретных условий:
1) Размер группы большой (более 1000000 записей) - в пользу нескольких таблиц 2) Количество групп большое - в пользу одной таблицы 3) Группы логически очень обособленные, практически не может быть запросов затрагивающих более одной группы - в пользу нескольких таблиц 4) Сложность запросов на таблице - при чрезмерно сложных запросах (когда уровень вложенности более 10 подзапросов) работать с более мелкими, но более структурированными таблицами легче 5) Необходимость разграничения прав доступа между группами - в пользу нескольких таблиц 6) Возможность переноса записи из одной группы в другую- в пользу одной таблицы и т.д. скорее всего имеет место сочетание факторов, и идеальных условий может не быть, в таком случае и идеальных решений тоже быть не может... -------------------- With the best wishes, Vit I have done so much with so little for so long that I am now qualified to do anything with nothing Самый большой Delphi FAQ на русском языке здесь: www.drkb.ru |
|||
|
||||
| m@kxus |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 110 Регистрация: 20.2.2003 Где: Estonia Репутация: нет Всего: 2 |
OnORACLE советую сделать так (это типа, база данных такая - ORACLE):
1. Таблица работников (ака. "помойка") - все вместе, например, PEOPLE. 2. Классификатор групп (отделов, складов, семейств) - таблица, где все групы, с названиями, адресами и тому подобной хернёй, например, GROUPS. В таблице ПИПИЛ делаем поле ГРУППА и связываем по FOREIGN KEY с таблицей ГРУПЗ. Какой в таблице ПИПЛ ключ - решать тебе. Скорее всего, это будет ID. Тока группу не надо в ключ - она будет нам излишнюю уникальность обеспечивать - оно нам надо? В таблице ГРУПЗ делай поле ГРУППА, где будет ID группы (отдела) и какой-нить там NAME, ADDRESS, ETC по своему усмотрению. Так, теперь появится мнение, что из-за громоздкости таблицы-"помойки" будут медленно запросы работать. Неа, ничё подобного! Творим PARTITIONы для каждой группы в таблице ПИПИЛ и вуаля! - нам обеспечена гибкая база данных, упорядоченые данные и быстрый доступ к оным. Добавление новых групп - это всего лишь добавление 1 (одной) записи в таблицу ГРУПЗ. Перетаскивание народа из группы в группу - это обновление всего лишь одного поля в таблице ПИПИЛ. Короче, порядок и цивилизованный подход. Пример запроса для группы с ID "DEPART1": SELECT * FROM PEOPLE PARTITION (DEPART1) WHERE SURNAME LIKE 'A%' ORDER BY NAME ... для кого-то это станет откровением свыше ... |
|||
|
||||
| Kolia |
|
|||
|
Шустрый ![]() Профиль Группа: Awaiting Authorisation Сообщений: 132 Регистрация: 11.7.2003 Где: Вильнюс Репутация: нет Всего: нет |
Вывод такой: делать с одной таблицей, т.к. я даже сомневаюсь, что в ней наберется и 100000 записей.
Все. --------------------
Риспект |
|||
|
||||
| m@kxus |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 110 Регистрация: 20.2.2003 Где: Estonia Репутация: нет Всего: 2 |
Kolia, ты почти прав...
|
|||
|
||||
![]()
|
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | MySQL | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |