DjangoBB LoFi version

Полная версия: Генерация кода с помощью ИИ

Начало » Флейм » Генерация кода с помощью ИИ

1 2 3 4 5 6

py.user.next

Июнь 14, 2025 06:07:19

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

wiki. en. relation

wiki. en. table

wiki. ru. таблица

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

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.

Здесь, видишь, прямо в международной среде путаница идёт и споры. Из-за понятия “таблица” и возникает эта путаница, потому что у таблиц есть ряд свойств, которых нет у отношений. Таблицы даже полностью не выражают отношения. Но база данных в общем виде построена именно на отношениях, а не на таблицах. Поэтому в базе данных не может быть двух полностью одинаковых строк. Это запрещено до первой нормальной формы ещё.

То, что ты называешь “реляционной алгеброй” - набор операций - не является всем тем материалом, который используется в базах данных. Просмотри первую ссылку на вики, там есть картинка, что такое отношение, и оно никаким боком к операциям не относится. Ни к операциям, ни к SQL-запросам. Там речь идёт о модели данных и о её устройстве - о том, как данные собраны друг с другом воедино - в единое отношение.

Поэтому когда говорят “реляционная - это потому, что между таблицами есть отношения relations, то есть реляции”, они путают два слова: relation и relationship. По-русски оба этих слова звучат как “отношение”, но это два разных отношения. Одно отношение - это математическое понятие, как “бинарное отношение”, например, а второе отношение - отношение чего-то к чему-то, связь между чем-то и чем-то. Поэтому безграмотные, не вдаваясь в подробности, и путают эти вещи между собой и точно не знают, почему и что как называется.

tags: database relation

py.user.next

Июнь 14, 2025 06:29:46

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

Я не знаком, ты тоже станешь незнакомым с этой областью года через три. Откроешь свою базу данных и не сможешь разобраться, где там что и почему, и что значат эти цифры 1 и 2 в именах, и почему они 1 и 2, а не 2 и 1 или 3 и 4. Я тебе серьёзно говорю: не полагайся на то, что ты будешь помнить хоть что-то в своей великой базе данных. Стоит тебе сделать ещё пяток таких проектов крупных тоже с базами данных и тоже с очень умными, и они перезатрут у тебя в памяти всё, что ты помнил до их появления.

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

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

Ну вот id и branch - два странных атрибута, которые почему-то оказались вместе. Там точно одного id не хватит для уникальности? Там точно не появится две одинаковых пары из этих атрибутов, типа (1,1) и (1,1)?

xam1816

Июнь 14, 2025 06:55:43

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

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

Rodegast

Июнь 14, 2025 14:17:14

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

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

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

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

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

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

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

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

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

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

Rodegast

Июнь 14, 2025 14:30:08

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

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

xam1816

Июнь 14, 2025 16:29:39

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

Тут всё относительно. Это можно сравнить с тем, когда человек что то умеет делать и хочет делегировать другому. Так вот пока объясняет ему как нужно делать, быстрее бы уже сам сделал.
Другой момент, когда человек не знает как что то сделать и пытается объяснить другому. Соответственно пока объясняет, тоже много времени уходит.
Буст тогда, когда ты очень чётко объясняешь, что тебе нужно. Абстрактный вопрос даст абстрактный ответ.

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

Прикол в том, что это она показала мне как нужно составлять запрос, чтобы был эффект.
Относительно меня, так я вообще поверхностно представляю что ты делаешь, тем не менее могу принять участие только с ИИ.

Rodegast

Июнь 14, 2025 17:25:59

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

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

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

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

py.user.next

Июнь 15, 2025 00:20:53

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

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

Так вот, когда ты разделяешь пачку номеров телефонов в отношении (есть у тебя список номеров телефонов человека и ты говоришь “не-е-е, я список номеров в базе хранить не буду, я эти номера человека разделю на отдельные номера и сделаю отдельное отношение для этого”), это ты приводишь отношение к первой нормальной форме. А если ты так и оставишь список, то ты потом получишь телефон и вопрос “чей это телефон?” и не сможешь его найти, потому что списки эти не подходят для поиска, для индексов там и тому подобного. Казалось бы, это просто теория, но весь мир, в том числе и ты, не понимая этого даже, сидит и нормализует по этой теории. Только ты ещё говоришь, что теорию надо брать не всю в целом и рассматривать целостно, а только нормализацию из неё взять, а дальше коверкать определения и термины, предполагая, что тебя все понимают одинаково. Ты говоришь “таблица” и человек думает про таблицу, упорядоченную. Он не думает, что ты говоришь про специальную таблицу. В итоге ты порождаешь путаницу.

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

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

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

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

Значит, ты неинформативно назвал этот атрибут в этом отношении. Ты можешь понять, что атрибут id в каждом отношении относится только к этому отношению? Вот есть отношение, отношение - это такой остров, он не знает про другие острова. И вот на этом острове возникает название id. Что это за название? Это название чего-то на этом острове. И на каждом острове во всём архипелаге может быть какой-то свой id. Десять островов и десять разных id. Так вот, чтобы назвать на одном острове с id другой id, который на другом острове есть, надо к id добавить суффикс хотя бы - id_left. Тогда из названия атрибута видно, что id центрального острова так и остался на месте, id левого острова так и остался на месте, а на центральном острове узнали про левый остров и назвали его элементы аналогично, но с суфиксами. Тогда, находясь на каждом острове мы всегда знаем, какие элементы его, а какие элементы с внешних островов взяты.

Атрибут id обычно идентифицирует объекты в отношении, в котором этот id и находится. Является первичным ключом. Почему я и спросил про него, почему у тебя уже первичный ключ находится в составе составного первичного ключа, ведь это запрещено второй нормальной формой.

Атрибут id называют ещё суррогатным первичным ключом. Он суррогатный потому, что сам по себе никакой информации не несет в отношении. Если его удалить, исчезнет лишь это упорядочивание в отношении, но не данные. Изначально первичный ключ берётся из данных отношения и это всё используется без введения суррогатных первичных ключей.

tags: database nf

Rodegast

Июнь 15, 2025 01:35:04

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

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

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

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

). Я в курсе что это разные вещи.

py.user.next

Июнь 15, 2025 23:31:51

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

Да, и тебе надо переходить на понятие отношение, когда ты нормализуешь. А отношение - это понятие из SQL?

В том-то и дело, что SQL везде разный ещё, там диалекты. То есть таблица в одной СУБД и таблица в другой СУБД тоже могут различаться.

А нормализация одна и она не меняется. Хоть сто СУБД появится, нормализация останется нормализацией.