9404
Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы, для поиска работы и предложения вакансий есть группа https://t.me/pgsqljobs For English discussion visit https://t.me/pg_sql
Возвращаясь к этому примеру , а что если к примеру url , budget + 3 свойства еще , прослеживается одна тематика , назовем это requirements (опять же название свойств от болды придумал , но будем считать что все они нужны для определенной задачи)
то есть мы положим их в таблицу requirements. В этом случае нам не придется создавать app_folders , user_folders
Что думаете ?
-----Old VersionЧитать полностью…
CREATE TABLE folders (
id SERIAL PRIMARY KEY,
folder_name VARCHAR(322) NOT NULL,
description VARCHAR (500),
parent_folder_id INT REFERENCES folders(id),
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
CREATE TABLE app_folders (
id SERIAL PRIMARY KEY,
folder_id INT UNIQUE REFERENCES folders(id) NOT NULL,
url TEXT ,
budget VARCHAR(200) NOT NULL,
---{+3 other properties}
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
CREATE TABLE user_folders (
id SERIAL PRIMARY KEY,
folder_id INT UNIQUE REFERENCES folders(id) NOT NULL,
user_id INT REFERENCES users(id) NOT NULL,
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
----- New Version
CREATE TABLE requirements {
id SERIAL PRIMARY KEY,
url TEXT ,
budget VARCHAR(200) NOT NULL,
---{+3 other properties}
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
}
CREATE TABLE folders (
id SERIAL PRIMARY KEY,
folder_name VARCHAR(322) NOT NULL,
description VARCHAR (500),
user_id INT REFERENCES users(id),
parent_folder_id INT REFERENCES folders(id),
requirement_id INT REFERENCES requirements(id),
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
Из читаемых аналогов uuid — SnowflakeId / SonyId и им подобные, в базе лежит как int64, длинный но куда более читаемый.
Из как бы минусов - параметры генерации не трогать совсем, то могут быть коллизии id при > 1000 INSERT в одну микросекунду.
Расширяем задачу. Есть posts и для app и для users и эти посты могут находится в folders . Для постов app будут доп свойства только для posts app. Я создаю таблицы posts(общие свойства) , app_posts(уникальные свойства для app) , user_posts. Я ссылаюсь user_posts => posts <= app_posts. Вопрос, с какого из них мне сослаться к папкам мне надо сослатсья posts => folders или user_posts => user_folders => folders , app_posts => app_folders => folders ? FK где указать
Читать полностью…
Спасибо за ответ. Можете подсказать, чем SERIAL может быть лучше?
Читать полностью…
Подскажите, пожалуйста, по современному стандарту SQL GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY предпочтительнее SERIAL? Или это совершенно не так?
Ну, можно и так. Только, кажется, синтетический id у user_folders излишен, т.к. там PK можно задать как композитный через (user_id, folder_id).
Читать полностью…
В "примере" тип folder не "базовый", а полноценный. И именно он то не расширяется по "смыслу". Опять же, можете смотреть на это с точки зрения композиции, если хотите.
Читать полностью…
Здесь я просто не понял , вы сказали что не стали бы создавать базовый folders к которому ссылались бы app_folders и user_folsers , а ниже вы показали такие же таблицы , да вы сказали что это похоже на наследование но это не то, но честно говоря я осталбиней не понял
Читать полностью…
В outbox паттерне же нужно знать id заранее (?)
Сначала в outbox записали, потом коммитим, и только после этого кафка узнаёт, что появилось новое событие же
Про uuid7v кстати неплохой вариант, спасибо
Коллега, только в этом чате, только текстом ;)
Читать полностью…
Здравствуйте!
Кейс: из приложения приходит запрос на insert продукта в табличку outbox, затем кафкой загружается в нужные таблицы. Вроде все ясно что куда грузить в payload, но не особо понятно что делать с айдишником - автоинкримент вроде как юзать нельзя так как продукт еще не создан, uuid - можно было бы и это самый простой способ создавать на стороне приложения (и не особо человокочитаемо), но хотелось бы именно числовой метод.
Из вариантов: nextval с батч запросами - такое подходит? Или есть еще варианты?
да , хотелось бы с примером. То есть вы говорите что даже если (user_folders, app_folders) имеют общие свойства мы не должны создавать и ссылаться на базовый folders ?
Читать полностью…
надеюсь , я понятно объяснил , если что спрашивайте
Читать полностью…
Видимо (до этого то я не знал, какую логику вы туда вкладываете). А чего напрягаться и плодить сущности без необходимости то.
Ко всему прочему это ещё и ≈самый производительный вариант.
Ну, кажется, folder_id логично хранить в post (потому что app/user_posts это связь между app/user и post, и отношения между post и folder к этой связи не относятся — т.е., они могут/должны жить отдельно и ничего друг про друга не знать).
* Построение структуры данных может быть не совсем тривиальной задачей (надо отталкиваться от различных факторов/требований к системе).
Например — шерить одну и ту же последовательность на N таблиц. Или использовать этот "генератор" не совсем по назначению, в кач-ве переменной в запросах в т.ч...
Короче говоря, "правила", в среднем, можно нарушать, если понимаешь что делаешь.
Предпочтительнее, официально. Но в serial нет ничего противозаконного (и иногда он может сделать то, чего identity не может).
Читать полностью…
Спасибо огромное! Заработало тут же в отличие от остального нагугленного шаманства (посчитать row_number, запрятать во вложенный селект и т. п.)
Читать полностью…
Вы так говорите ? я добавил парочку свойств для папок приложения (то есть эти свойства будут только у папок приложения)
никакого смысла они не несут , просто как пример накидал
Читать полностью…
CREATE TABLE folders (
id SERIAL PRIMARY KEY,
folder_name VARCHAR(322) NOT NULL,
description VARCHAR (500),
parent_folder_id INT REFERENCES folders(id),
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
CREATE TABLE app_folders (
id SERIAL PRIMARY KEY,
folder_id INT UNIQUE REFERENCES folders(id) NOT NULL,
url TEXT ,
budget VARCHAR(200) NOT NULL
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
CREATE TABLE user_folders (
id SERIAL PRIMARY KEY,
folder_id INT UNIQUE REFERENCES folders(id) NOT NULL,
user_id INT REFERENCES users(id) NOT NULL,
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
Ну, вы можете получить возвращенное значение от последовательности PostgreSQL до коммита (больше того — при откате транзакции, состояние последовательности то никуда не откатывается, если не применить спец. грязные хаки серии "из спортивного интереса").
Короче говоря, вы от INSERT через RETURNING можете получить оный id, и далее использовать его где "следует" (если я верно понял вашу задачу)...
Красотку на знакомство уломать и то легче , чем вас на личное общение))
Читать полностью…
автоинкримент вроде как юзать нельзя так как продукт еще не создан
затем кафкой загружается в нужные таблицы
но хотелось бы именно числовой метод
А в дискорде поговорить можем ? Хотелось бы донести мысль , печатая всё это можно задолбатся. У вас опыта по больше в этом , иначе бы я этого не спрашивал
Читать полностью…
даже если (user_folders, app_folders) имеют общие свойства мы не должны ссылаться на базовый folders
хотелось бы с примером
В предложениях выше я исходил из того, что папка — одинаковая сущность, даже для разных типов владельцев.
Если бы это были разные сущности, то я бы просто развалил их на две отдельные таблицы (user_folders, app_folders), и ни в коем случае не "наследовал" бы их от какого-то базового типа, т.к. это приведет скорее к проблемам а не к пользе.
С другой стороны, иногда доп. атрибуты указывают прямо в таблицах связи — это тоже вариант. Но здесь важно отметить, что сущность по-прежнему одинакова, просто есть именно доп. атрибуты связи для конкретных типов (если надо, могу накатать какой-то пример).
а что если для папок добавленные приложением , ,были бы доп свойства , то есть у папок users этих свойств не было бы , вы бы выбрали тогда второй вариант ? или же первый и сделали бы поля предназначенные для app null (там где папка для user) ?
Читать полностью…
ну значит ты выбираешь первый вариант , хорошо
Читать полностью…