Pers_id
name
descr
category
something
Проектирование базы данных
Доброго времени суток, мне необходимо мнение/совет человека, имеющего опыт в проектировании баз данных.
Работа с БД происходить слеюущим образом:
1. Для каждого нового пользователя создается таблица-каталог вида:
cat1
___
* id
* name
* descr
* category
* something
2. Данные таблиц пользователей заносятся в общую таблицу вида:
base
___
* id
* name
* descr
* category
* owner
Принцип импортирования: ищем cat1.name среди base.name
* если записи не существует - создаем
* если существует - добавляем в поле base.owner - id из названия таблицы (cat1 -> добавляем 1)
3. Во время работы возникнет необходимость по base.id вытаскивать cat1.something для каждого base.owner
Пользовательских таблиц cat будет несколько десятков. Из base owner будут браться id (их может быть несколько), через которые будут происходить обращения к нужным таблицам (1 -> cat1).
Мое мнение - данная реализация довольно некрасивая, но опыта в проектировании нет и пока других вариантов не придумал.
4. Мы определили таблицы, теперь необходимо найти внутри них нужную запись. Я собираюсь искать ее по совпадению base.name - catN.name.
На этом все, я уверен, что необходимые записи я найду, но я не уверен в рациональности поиска по текстовому полю name в пункте 4 и поиску таблицы в пункте 3.
Просьба скажите, что вы думаете по поводу данной реализации и как мне следует оптимизировать схему?
Спасибо за внимание.
Работа с БД происходить слеюущим образом:
1. Для каждого нового пользователя создается таблица-каталог вида:
cat1
___
* id
* name
* descr
* category
* something
2. Данные таблиц пользователей заносятся в общую таблицу вида:
base
___
* id
* name
* descr
* category
* owner
Принцип импортирования: ищем cat1.name среди base.name
* если записи не существует - создаем
* если существует - добавляем в поле base.owner - id из названия таблицы (cat1 -> добавляем 1)
3. Во время работы возникнет необходимость по base.id вытаскивать cat1.something для каждого base.owner
Пользовательских таблиц cat будет несколько десятков. Из base owner будут браться id (их может быть несколько), через которые будут происходить обращения к нужным таблицам (1 -> cat1).
Мое мнение - данная реализация довольно некрасивая, но опыта в проектировании нет и пока других вариантов не придумал.
4. Мы определили таблицы, теперь необходимо найти внутри них нужную запись. Я собираюсь искать ее по совпадению base.name - catN.name.
На этом все, я уверен, что необходимые записи я найду, но я не уверен в рациональности поиска по текстовому полю name в пункте 4 и поиску таблицы в пункте 3.
Просьба скажите, что вы думаете по поводу данной реализации и как мне следует оптимизировать схему?
Спасибо за внимание.
Сказать что либо по поводу схемы не возможно, не понимая чего вы хотите добится.
Например - зачем создавать отдельную таблицу?
Например - зачем создавать отдельную таблицу?
Не знаю ваших конечных целей, но скажу сразу, что подход при котором кол-во таблиц завязывается на такую меняющуюся величину, как кол-во пользователей - плохой подход. Не реляционный.
Вам лучше перепроектировать свою БД таким образом, чтобы пользователю соответствовала строка/строки в таблице а не отдельная таблица. Напрмер сделайте постоянную таблицу структуры cat1 и добавьте туда еще одно поле catID, в котором будет храниться принадлежность группы строк к определенному пользователю. Это позволит вам избежать динамического sql, позволит создать на таблице нормальные индексы и вообще убережет от таких извратов как сейчас =)
Вам лучше перепроектировать свою БД таким образом, чтобы пользователю соответствовала строка/строки в таблице а не отдельная таблица. Напрмер сделайте постоянную таблицу структуры cat1 и добавьте туда еще одно поле catID, в котором будет храниться принадлежность группы строк к определенному пользователю. Это позволит вам избежать динамического sql, позволит создать на таблице нормальные индексы и вообще убережет от таких извратов как сейчас =)
У каждого пользователя в каталоге будет несколько десятков тысяч записей. Периодически эти записи будут обновляться, отдельные таблицы делаю для того, чтобы не заморачиваться с очисткой таблицы, а полностью удалять ее содержимое и заполнять заного.
SomewherSomehow, ваш вариант вполне приемлимый и действительно реляционный, надеюсь, особой потери производительности от перехода с drop table до очистки записей по catID не будет.
SomewherSomehow, ваш вариант вполне приемлимый и действительно реляционный, надеюсь, особой потери производительности от перехода с drop table до очистки записей по catID не будет.
Не волнуйтесь, для более менее серьезной субд, несколько десятков тысяч записей - не проблема. Некоторые таблицы запросто измеряются десятками миллионов и то, считаются не такими уж большими. И потом при создании-удалении таблиц скорее всего будут наклядываться более строгие блокировки, чем при удалении строк.
Самое главное правильно организовать индексы в таблице.
Удачи!
Самое главное правильно организовать индексы в таблице.
Удачи!
ТС не указал СУБД. Лучше былоб указать.
А смысл? Мне почему-то сейчас подумалось, что разрабатывать структуру БД лучше таки не привязываясь к определенной СУБД, хотя может я и неправ.
Для того чтобы не заморачиваться с удалением данных из БД при удалении пользователя существует схема данных защита целосности подчиненных записей. Если поставить в настройках связей между таблицами автоматическое удаление подчиненных записей при удалении главной то они все будет как Вам надо
создаете таблицу
Pers
Создаете таблицу записей
rec_tab
Поля Pers_id и Rec_id являются уникальными в своих таблицах и их записи не могут повторятся
Записи Поля id_pers могут повторятся но в данном поле не может быть таких значений которых нет в поле Pers_id
создаете связь можду таблицами Pers_id<->id_pers (один ко многим) и ставите галку о проверки целосности и автоматическом удалении данных и подчинненной таблицы.
И все.
Записи в таблице Res_tab от определнного пользователя ищутся запросом по полю id_pers.
При удалении из таблицы Pers пользователя удаляются все его записи из таблицы Rec_tab
Удачи!!!
создаете таблицу
Pers
Код:
Создаете таблицу записей
rec_tab
Код:
rec_id
id_pers
descr
category
id_pers
descr
category
Поля Pers_id и Rec_id являются уникальными в своих таблицах и их записи не могут повторятся
Записи Поля id_pers могут повторятся но в данном поле не может быть таких значений которых нет в поле Pers_id
создаете связь можду таблицами Pers_id<->id_pers (один ко многим) и ставите галку о проверки целосности и автоматическом удалении данных и подчинненной таблицы.
И все.
Записи в таблице Res_tab от определнного пользователя ищутся запросом по полю id_pers.
При удалении из таблицы Pers пользователя удаляются все его записи из таблицы Rec_tab
Удачи!!!
Только к скорости и производительности это не имеет никакого отношения.