LINUX.ORG.RU

Избежать кучи таблиц в Postgres'е

 


0

1

Привет, ЛОР.
Вопрос такой: есть сервис, есть его БД в постгресе, у этого сервиса, допустим, 1000 пользователей.

Для каждого пользователя имеется возможность создания таблички кастомной обработки правил (пусть это будут правила совершения вызовов на телефон пользователя), так вот, вопрос — как правильнее всего поступить?


1 вариант — табличка обработки вызовов для всех общая;

table_rules
---------------------------------
owner | phone | ruleid | ...


И к каждому правилу мы приписываем owner и phone, что, как мне кажется, не есть правильно.

2 вариант — табличка под каждый номер телефона:

table_12000000001_rules
---------------------------------
ruleid | ...


Но тогда в «корне» БД будут сотни, тысячи таких таблиц, что тоже, наверное, не есть хорошо.

Может, есть ещё какие-то варианты?
Как это грамотнее реализовать в postgresql?

★★★★☆

Сделай для owner,phone — уникальный ключ и приписывай его, а для owner,phone ключ другая таблица.

Evgueni ★★★★★
()

Отдельная таблица с пользователями, отдельная таблица с правилами, отдельная таблица для связки "кто звонит" (references users(id)), "кому звонит" (references users(id)), "правило" (references rules(id))

micronekodesu ★★★
()

Одна таблица. man индексы.

slovazap ★★★★★
()

Конечно первый вариант.

Legioner ★★★★★
()

И к каждому правилу мы приписываем owner и phone, что, как мне кажется, не есть правильно.

1) Почему кажется?

2)

table_rules
---------------------------------
owner | phone | ruleid | ...

Два разных пользователя могут завести в базу один и тот же номер телефона? Т.е. на таблице phones нет констрейнта? Если не могут, тогда зачем этот странный составной ключ?

thomasbug
()

Как уже сказали:

CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    name ...,
    phone ...,
    ...
)

CREATE TABLE rules (
    id SERIAL PRIMARY KEY,
    account_id SERIAL REFERENCES accounts(id) ON DELETE CASCADE,
    ...
)

Deleted
()
Ответ на: комментарий от thomasbug

С точки зрения бизнеса - вполне могут, переехать телефонный номер сейчас - ни разу не проблема. Пущай будет составной

Deleted
()
Ответ на: комментарий от thomasbug

Да изменить схему - не проблема. Нужно просто до автора донести идею foreign key. А хранить по таблице на тело - это какое-то извращение.

CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    name ...,
    ...
)

CREATE TABLE phones (
    id SERIAL PRIMARY KEY,
    account_id SERIAL REFERENCES accounts(id) ON DELETE CASCADE,
    phone ...,
    ...
)

CREATE TABLE rules (
    id SERIAL PRIMARY KEY,
    phone_id SERIAL REFERENCES phones(id) ON DELETE CASCADE,
    ...
)

Deleted
()
Ответ на: комментарий от Deleted

а зачем составной-то?

вы что тут все заторможенные как и ОП?

phones
-------- ----------- ------------
phone_id customer_id phone_number


rules
------- -------- ----------------
rule_id phone_id rule_description
thomasbug
()

Чтоб ты знал, тысяча пользователей это фигня. Первый вариант + индексы правильный.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.