Как сделать один идентификатор на 2 таблицы?

Question

[nepster-web]

Задачка сделать один идентификатор (авто инкремент) на 2 таблицы.
Собственно есть данные и демо данные, они должны залетать в 2 разные таблицы, но при этом для корректного обращения на фронте у них не должны пересекаться айдишники.

Тоесть, если залетает 3 демо записи в одну таблицу, то не демо запись залитает в следующую с идентификатором 4.

Как я понял вариант - партиции, однако не совсем понятно, как создать подобное правило.

Comments

[FanatPHP]

это какой-то бред
с какой стати эти таблицы вообще пересекаются?

[MaLuTkA_UA]

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

Вот ссылка на доку, почитайте: https://postgrespro.ru/docs/postgresql/10/ddl-part...

Answer 1

[Сергей Горностаев]

Идея дурацкая, если честно, но сделать можно:

create sequence shared_sequence;
create table production_data(id bigint default nextval('shared_sequence'), value text);
create table demo_data(id bigint default nextval('shared_sequence'), value text);

Comments

[nepster-web]

Хм. Выглядит не плохо. А почему идея дурацкая ? В плане этой реализации или в плане разделения таблиц в целом ?

[Сергей Горностаев]

nepster-web, не могу представить ни малейшей причины для того, чтобы заводить для демонстрационных данных отдельную таблицу, делать сквозную нумерацию и вообще иметь демонстрационные данные на одном сервере с продовыми. Выглядит как костыль и потенциальный источник проблем.

[nepster-web]

Сергей Горностаев,
Получается у нас есть некая игра, где происходят финансовые операции. И они делаются достаточно часто. Тоесть таблица разростается очень быстро. Эти данные критичны для пользователей.

Также пользователям предлагается демо счёт , где можно все тоже самое проделать с демо валютой, логика один в один. Разница в том, что демо данные не особо важны.

Вначале это все было в одной таблице и таблица эта раздувается очень быстро. При этом в некоторых случаях демо данные могут мешать. Так и возникла задача вынести это отдельно.

Что касается отдельных серверов , баз данных и сервисов - не на столько большой проект и этап развития данного проекта, чтобы внедрять подобное решение. Это так сказать мвп :)

[Сергей Горностаев]

nepster-web, если бы не это

При этом в некоторых случаях демо данные могут мешать.

Я бы лучше добавил в таблицу поле, отмечающее демонстрационные данные.

[nepster-web]

Сергей Горностаев, по сути это текущее положение дел, в которое я хочу чуть вмешаться =).

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

Answer 2

[Михаил]

В Postgresql нет автоинкремента, в postgresql есть последовательности (sequence).
Собственно берите значение (nextval) из одного и того же сиквенса при вставке записи в обе таблицы - получите то что вам нужно.

Answer 3

[nApoBo3]

Вам в любом случае поддерживать логику этого ключа за пределами базы.
Можно сделать не пересекающиеся инкримент( один от 1 до 100, второй со 101 до 200, типа того ) можно внешнюю таблицу, можно отказаться от числового ключа и использовать uuid.

Comments

[nepster-web]

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

Answer 4

[Myclass]

А я-бы с id на key перешёл. Тогда не только две таблицы но десять nodes смогут одно и тоже параллельно обрабатывать и сохранять. Те. Key описывает record, а не какое-то случайно генерированное id.