Допустим есть какая-то база рабочих. Все они объединены в группы. Что выгодней, для каждой группы создать отдельную таблицу, или всех рабочих держать в одной. В перспективе количество групп будет расти.

Посоветуйте (вопрос бывалым).

зависит от задач, которыми ты будешь нагржуать эту/эти таблицу(ы)

Цитата(Cepera @ 26.8.2003, 11:28)

зависит от задач, которыми ты будешь нагржуать эту/эти таблицу(ы)

Основная задача - это вывод участников какой-то группы, добавление новых участников в группу, добавление новой группы.

Меня просто терзают сомнения. Уже все готово. Для каждой группы своя таблица. А если таких групп наберется 100, хотя в каждой из них может быть только 2 участника. А может и 100, 200.

ну до пары сотен тысяч записей можешь спать спокойно

Значит с одной таблицей?

Зависит от объёма, если таблица небольшая - не больше 10 000 000 записей - то нет проблем, должна работать как одна нормально (при правильно подобранных индексах и правильно составленных кверях), а если таблица содержит больше 10 миллионов записей, то разбиение её на несколько таблиц может увеличить производительность

Не могу себя назвать крупным специалистом в БД, но мне кажется, что нехорошо, когда структура БД (количество таблиц) зависит от количественных показателей предметной области (количество групп).
Представим себе: кто-то хочет смотреть информацию про всех людей (например, их количество)
для него будет написана программка, которая выдает ему это значение
если каждой группе будет соответствовать своя таблица, то все они должны быть перечислены в запросе
значит, при добавлении новой группы придется открывать исходники этой программки, добавлять новую таблицу в запрос, компилировать заново и т.д., и т.п.
и так - для всех подобных программ... (ужас)

Цитата(maxim1000 @ 26.8.2003, 16:01)

Не могу себя назвать крупным специалистом в БД, но мне кажется, что нехорошо, когда структура БД (количество таблиц) зависит от количественных показателей предметной области (количество групп). Представим себе: кто-то хочет смотреть информацию про всех людей (например, их количество) для него будет написана программка, которая выдает ему это значение если каждой группе будет соответствовать своя таблица, то все они должны быть перечислены в запросе значит, при добавлении новой группы придется открывать исходники этой программки, добавлять новую таблицу в запрос, компилировать заново и т.д., и т.п. и так - для всех подобных программ... (ужас)

Ты видать и в програмировании не очень. Можно узнать имена всех таблиц в базе. Так как имена таблиц с участниками группы очень строгое, то можно легко выводить всех участников.
Ну да пофиг. 1000000 записей в таблице точно не наберется

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

Советую в первую очередь прочитать про три основыне формы нормализации БД. Эта тема как-раз рассматривает вопросы такого рода.

Да, хочу сказать сразу, таблица-помойка (где все сразу) - это не есть гуд.

Pegas

Полностью с тобой согласен!

Цитата(Pegas @ 28.8.2003, 10:37)

Советую в первую очередь прочитать про три основыне формы нормализации БД. Эта тема как-раз рассматривает вопросы такого рода.

А где прочитать можно? Не подскажешь

Цитата(Pegas @ 28.8.2003, 10:38)

Да, хочу сказать сразу, таблица-помойка (где все сразу) - это не есть гуд.

Так как мне разбить эту таблицу-помойку? Альтернатива - каждой группе по таблице. Только сколько таблиц набраться может.

Вот структура "таблицы-помойки":

| ID | Group | User |

Ну, кто ее разобьет?

в твоем формате:
tables:
| table_id | table_name |
users:
| user_id | table_id | user_name |

Цитата

Так как мне разбить эту таблицу-помойку? Альтернатива - каждой группе по таблице. Только сколько таблиц набраться может.

когда нам в институте читали курс по БД, нам рассказывали о таком понятии, как роль, это немного похоже на наследование
например, сущность "рабочий склада" может служить ролью для сущности "рабочий"
при использовании ролей информация общая для всех рабочих (имя, фамилия, дата рождения, ...) хранится в одной "таблице-помойке" , а информация специфичная для группы рабочих склада (например, номер склада, в котором он работает) хранится в отдельной таблице, в которой есть ID рабочих из общей таблицы
если же набор сведений для всех рабочих одинаковый, непонятно, зачем вводить разные таблицы

Цитата

Так как имена таблиц с участниками группы очень строгое

переносить бизнес-логику на такие вещи, как имена таблиц, IMHO не лучший подход

В общем виде такая задача не решается. Зависит от конкретных условий:

1) Размер группы большой (более 1000000 записей) - в пользу нескольких таблиц
2) Количество групп большое - в пользу одной таблицы
3) Группы логически очень обособленные, практически не может быть запросов затрагивающих более одной группы - в пользу нескольких таблиц
4) Сложность запросов на таблице - при чрезмерно сложных запросах (когда уровень вложенности более 10 подзапросов) работать с более мелкими, но более структурированными таблицами легче
5) Необходимость разграничения прав доступа между группами - в пользу нескольких таблиц
6) Возможность переноса записи из одной группы в другую- в пользу одной таблицы


и т.д. скорее всего имеет место сочетание факторов, и идеальных условий может не быть, в таком случае и идеальных решений тоже быть не может...

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

... для кого-то это станет откровением свыше ...

Вывод такой: делать с одной таблицей, т.к. я даже сомневаюсь, что в ней наберется и 100000 записей.

Все.

Kolia, ты почти прав...