Python-сообщество

Rodegast
Таблица это термин используемый в официальном описании стандарта SQL.

Отношения и их представление в виде таблиц
править
Отношение обычно имеет простую графическую интерпретацию в виде таблицы, столбцы которой соответствуют атрибутам, а строки — кортежам, а в «ячейках» находятся значения атрибутов в кортежах. Тем не менее, в строгой реляционной модели отношение не является таблицей, кортеж — это не строка, а атрибут — это не столбец. Термины «таблица», «строка», «столбец» могут использоваться только в неформальном контексте, при условии полного понимания, что эти более «дружественные» термины являются всего лишь приближением и не дают точного представления о сути обозначаемых понятий.

Tables versus relations
edit
In terms of the relational model of databases, a table can be considered a convenient representation of a relation, but the two are not strictly equivalent. For instance, a SQL table can potentially contain duplicate rows, whereas a true relation cannot contain duplicate rows that we call tuples. Similarly, representation as a table implies a particular ordering to the rows and columns, whereas a relation is explicitly unordered. However, the database system does not guarantee any ordering of the rows unless an ORDER BY clause is specified in the SELECT statement that queries the table.

An equally valid representation of a relation is as an n-dimensional chart, where n is the number of attributes (a table's columns). For example, a relation with two attributes and three values can be represented as a table with two columns and three rows, or as a two-dimensional graph with three points. The table and graph representations are only equivalent if the ordering of rows is not significant, and the table has no duplicate rows.

Отредактировано py.user.next (Июнь 14, 2025 06:20:58)

Rodegast
Названия вполне информативные. Ты не знаком с предметной областью по этому так и показалось.

Rodegast
> У тебя точно нет суррогатных первичных ключей в смеси с другими ключами

С какими другими?

Отредактировано py.user.next (Июнь 14, 2025 06:31:09)

Rodegast
Мне надо копировать только определённую схему, а не всю ветку.

 CREATE OR REPLACE FUNCTION copy_schema_between_branches(
    source_branch UUID,
    target_branch UUID,
    func_id UUID
) RETURNS void AS $$
BEGIN
    -- Копируем элементы
    INSERT INTO elements (branch, id, func, type, text, idx, csv_status)
    SELECT
        target_branch,
        id,
        func,
        type,
        text,
        idx,
        csv_status
    FROM elements
    WHERE branch = source_branch AND func = func_id;
    -- Копируем связи (nexus)
    INSERT INTO nexus (branch, element_1, element_2, point_1, point_2, csv_status)
    SELECT
        target_branch,
        element_1,
        element_2,
        point_1,
        point_2,
        csv_status
    FROM nexus
    WHERE branch = source_branch
      AND (element_1 IN (
            SELECT id FROM elements WHERE branch = source_branch AND func = func_id
          ) OR element_2 IN (
            SELECT id FROM elements WHERE branch = source_branch AND func = func_id
          ));
END;
$$ LANGUAGE plpgsql;

 SELECT copy_schema_between_branches(
    'source-branch-uuid'::uuid,
    'target-branch-uuid'::uuid,
    'func-id-uuid'::uuid
);

🎯 Цель:
Создать хранимую процедуру, которая копирует схему (иерархию элементов) из одной ветки в другую.

📌 Уточнения:
Схема — это все elements, связанные через func = :func_id, плюс их связи в nexus.

Копируется только одна схема (по func).

Ветки (branch) различаются — копируем в новую ветку, указав её явно.

Ссылки и UUID-ы сохраняются — никакой генерации новых UUID-ов.

Обновлять/пересчитывать связи не нужно.

🧩 Влияние на таблицы:
elements:

копируются строки, где func = :func_id и branch = :source_branch

у новых строк — всё то же, но branch = :target_branch

nexus:

копируются строки, где branch = :source_branch и element_1 или element_2 ссылается на элемент из схемы

у новых строк — всё то же, но branch = :target_branch

> Из-за понятия “таблица” и возникает эта путаница, потому что у таблиц есть ряд свойств, которых нет у отношений.

Специально для тебя в третий раз повторяю. Реляционная алгебра и QSL это разные вещи. Первая имеет только теоретическое значение и на практике не была реализована, в место неё QSL который имеет свою терминологию и ряд отличий. ЗАБУДЬ ПРО ОТНОШЕНИЯ!

> Поэтому когда говорят “реляционная - это потому, что между таблицами есть отношения relations, то есть реляции”

А это вообще причём?

> Я не знаком, ты тоже станешь незнакомым с этой областью года через три.

Если я её забуду, то за пару часов вспомню и всё встанет на свои места.

> Ну вот id и branch - два странных атрибута, которые почему-то оказались вместе.

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

> Там точно не появится две одинаковых пары из этих атрибутов, типа (1,1) и (1,1)

С чего они появятся если там первичный ключ?

> на примере его, нужно описывать задачу, и чем больше подробностей, тем более точнее будет ответ

С третьей попытки она написала запрос который будет работать. Но его надо переделывать на материализованные CTE и про таблицу shema_scope она забыла… И собственно в чём буст?

Отредактировано Rodegast (Июнь 14, 2025 14:30:35)

Rodegast
И собственно в чём буст?

Rodegast
С третьей попытки она написала запрос который будет работать.

> Буст тогда, когда ты очень чётко объясняешь, что тебе нужно. Абстрактный вопрос даст абстрактный ответ.

Запрос который мне был нужен пишется минут за 10-15. Для чёткого формулирование задачи под ИИ я потрачу больше времени и получу не гарантированный результат.

> я вообще поверхностно представляю что ты делаешь, тем не менее могу принять участие только с ИИ

В твоём случае это нормально. Но если бы ты был в теме, то думаю что ИИ был бы абсолютно лишним.

Rodegast
Первая имеет только теоретическое значение и на практике не была реализована, в место неё QSL который имеет свою терминологию и ряд отличий.

Rodegast
А это вообще причём?

Rodegast
id - идентификатор сущности, branch - идентификатор ветки. Поскольку разные версии одной и той же сущности находятся в разных ветках в таком ключе ничего странного нет.

Отредактировано py.user.next (Июнь 15, 2025 00:31:46)

> Как раз в первой и проводится нормализация базы данных.

И причём тут нормализация? SQL её не отменяет, собственно как и модель сущность-связь.

> утверждали, что реляционная база данных потому реляционная, потому что у неё МЕЖДУ ТАБЛИЦАМИ ЕСТЬ ОТНОШЕНИЯ, А ОТНОШЕНИЕ - ЭТО RELATION по-английски.

Да, чебурашки часто путают отношения и модель сущность-связь (а ещё они для понтов называют таблицы отношениями ). Я в курсе что это разные вещи.

Rodegast
И причём тут нормализация? SQL её не отменяет