• Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru, ?? Шо б я понял, что такое "работать со складами и магазинами".
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru,
    а если учитывать, что магазин и склад - это совершенно разные физические объекты с совершенно разными задачи, где общее только то, что кокнретный товар только хранится?

    Да хоть в космос запусти. Это не влияет вообще ни на что. От слова "совсем".

    у нас есть:
    1. Множество магазинов
    2. Множество складов
    3. Множество товаров
    И, соответственно, куча комбинаций экземпляров одной сущности с двумя другими.

    Есть Товар. Наименование там, характеристики и прочее. Это не более чем описание. Есть квант (неделимая порция, единица) товара - вот именно они хранятся. И каждый квант Товара может соответствовать (храниться) только одному Месту хранения (складу или магазину). Так что никакой кучи комбинаций нет и в помине. Может для квантов Товара существовать надгруппа Партия товара - с целью уменьшения количества записей, но ценой усложнения логики контроля целостности.

    Зоны разные территориально, в каждой свои магазины и склады.

    Зона поставок вообще не сущность. Это атрибут места хранения - обычная справочная надгруппа.
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru, я на 100% согласен с Everything_is_bad. Магазин и Склад - это одна и та же сущность "Место, где хранится товар". Да, они различаются атрибутами - но не более. То же относится и к "Товар на складе" и "Товар в магазине" - это по смыслу вообще не сущность, а Junction table, пусть и с дополнительными атрибутами. И в первую голову надо переделывать схему.

    Что же до "пересечения" - я лично его в упор не вижу. Зато я вижу, что эта схема совершенно не позволяет выполнять контроль непротиворечивости данных на уровне БД. Причина чему - явная избыточность данных. Как по мне, следует вообще всё это потереть и начать заново, но начать с нормального анализа предметной области. И базовой сущностью при этом анализе должен быть квант товара, а вовсе даже не места хранения и не выполняемые с товаром операции. Сами же склады и магазины - это вообще вторичные контейнеры, выполняющие логическую группировку экземпляров основной сущности.
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    Это то что пишу в триггере:
    SELECT number INTO num FROM phone_item_number_1 WHERE item_id = id;
    INSERT INTO object_param_value_text (object_id, param_id, value) VALUES (NEW.object_id, 1, num);

    Ну вообще-то это можно делать и в один INSERT .. SELECT запрос - но при условии, что запись в phone_item_number_1 уже существует, и при этом строго одна:
    INSERT INTO object_param_value_text (object_id, param_id, value) 
    SELECT NEW.object_id, 1, number FROM phone_item_number_1 WHERE item_id = id;

    Тут есть проблемы. Если запись отсутствует - ничего не вставится. Если их более одной - вставится несколько строк.
    Можно использовать иначе:
    INSERT INTO object_param_value_text (object_id, param_id, value) VALUES 
    (NEW.object_id, 1, (SELECT number FROM phone_item_number_1 WHERE item_id = id));

    Тут при отсутствии записей будет вставлена одна запись с NULL. Но при наличии нескольких записей будет ошибка.

    -----------------

    Я что-то совсем потерялся в происходящем.

    Есть таблица Договоров. Есть таблица Объектов. Как я понимаю, записи в каждой из таблиц создаются совершенно независимо. Однако в таблице Договоров есть поле связи/ссылки с Объектом (договор может ссылаться только на один Объект, или ни на один). Значение в этом поле может либо присваиваться в момент создания записи при INSERT, либо указываться в дальнейшем при UPDATE. По-моему, так.

    Вы показываете схему, в которой присутствует аж 4 таблицы. И вот я не до конца понимаю привязки. Что из них таблица объектов? что таблица договоров? где поле связи (я не вижу внешних ключей)? каково назначение остальных двух таблиц?

    На будущее рекомендация: если поле в таблице А ссылается на поле в таблице Б (пусть даже без внешнего ключа, клиентской логикой) - делайте этим полям абсолютно одинаковые имена, понятно, уникальные в пределах схемы. Потом проще разбираться. Да и синтаксис JOIN USING прозрачнее и понятнее, чем JOIN ON.

    А теперь к логике.

    Создаётся Договор - запись в таблице ???. В ней есть поле ???, которое может быть ссылкой на Объект. Сам объект хранится в таблице ???, соответствующее поле для связи ???. (для оставшихся двух таблиц) Таблица ??? содержит ??? для таблицы ???, связывание происходит по выражению ???.??? = ???.??? - вот как-то так.

    Если в таблице Объект уже имеется запись, и в поле таблицы Договоров при вставке новой записи (INSERT) должна быть вставлена ссылка, то запись, из которой берётся значение для ссылки, берётся по выражению ???.??? = ???.???

    Если такая ссылка в таблицу Договоров добавляется уже в существующую запись (UPDATE), то запись в таблице Объектов, из которой следует взять значение поля ???, берётся по выражению ???.??? = ???.???

    Задача создаваемого триггера, определяемого на таблице ??? при выполнении операции ??? состоит в том, чтобы получить значение поля ??? из таблицы ??? и записать его в поле ??? таблицы ???
    Написано
  • Как заблокировать данные за предыдущий день?

    @Akina
    Требуется в конце каждого дня "замораживать данные" за каждый пройденный день

    Если надо замораживать только срез данных на конец дня, то лучше копировать этот срез в отдельную таблицу.
    Если надо сохранять состояние всего массива данных, то поможет только timeline (т.е. данные только добавляются, никаких изменений и удалений).
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Pro_Hacker, угу, можно... но в MySQL это либо стопицот функциональных индексов, либо фуллскан.
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Дмитрий Беляев, ну да. Во втором варианте предлагается разреженная таблица. Но её использование никоим боком не денормализация - как бы ни различались экземпляры разных типов, это всё одна и та же сущность.
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Дмитрий Беляев, Я вижу:
    create table products(product_id int, steam_level int, telegram_is_premium boolean)

    product_id - внешняя ссылка, как я понимаю.
    steam_level - ну... наверное, можно возможные значения вынести в отдельную таблицу, но как по мне, то оно не стоящее дело. Тогда уж CHECK constraint или вообще ENUM.
    telegram_is_premium - тоже как-то выносить странненько.

    Что декомпозировать-то?
    Написано
  • Можно ли через VBA сделать отправку уведомлений на почту?

    @Akina
    А какие сложности-то? Если в системе есть обработчик SimpleMAPI, то задача несложная. Объектная модель вполне доступна.
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    ПО создает в таблице объектов пустой объект со своим id (под пустым я понимаю то, что в других таблицах у него нет параметров с его ID) и в таблице договоров присваивает его id в ячейке в столбце id_объекта для того чтобы как-то связать их. Есть так же еще пара таблиц которые отвечают уже за параметры присваеваемые данному объекту. Таблица для параметров типа текст, типа список и типа флаг. Моя задача заключается в том чтобы в момент создания данного ПУСТОГО объекта, у которого отсутствуют параметры, подхватить данные с договора и насунуть их в эти параметры, которые будут созданы триггерром и обозначены ID соответствующим данному объекту.

    То есть, если я верно понимаю происходящее, то:

    1. ПО создаёт запись в таблице объектов и получает её ID.
    2. ПО создаёт запись в таблице договоров, и в поле ссылки на объект использует полученный ID.

    Это - верно? Если так - то я бы ориентировался на создание записи именно в таблице договоров, и именно в её BEFORE INSERT триггере присваивал необходимые значения полям этой таблицы. А сами значения параметров передавал бы через пользовательскую переменную.

    Моя базовая задача конкретно здесь, план минимум - это BEFORE UPDATE phone_client_item_1
    сделать INSERT INTO (object_id, param_id, value)
    где VALUES будут (NEW.object_id, 1, num), где num - это результат SELECT number INTO num FROM phone_item_number_1 WHERE item_id = id;

    То есть на момент UPDATE phone_client_item_1 уже имеется соответствующая запись в phone_item_number_1?

    Всё стало совсем непонятно. Пожалуйста, добавьте INSERT INTO с 2-3 начальными записями на таблицу, потом приведите все запросы, которые выполняет указанное ПО, с какими-то значениями (все значения должны быть уникальны в пределах всех показанных запросов, т.е. которые невозможно перепутать), и после каждого запроса от ПО, если надо что-то сделать дополнительно, укажите точно, что и где дополнительно должно произойти.

    Почему на этапе INSERT INTO используя конструкцию NEW.column_name я получаю ничего.

    Это верно только для автоинкрементных полей. Генерация автоинкремента будет выполнена только после всех триггеров, и только если значение после всех триггеров равно нулю. Даже если для него в запросе было явно указано NULL - ведь поле является первичным ключом, и соответственно NOT NULL. См. https://dbfiddle.uk/eVEpy39j
    Написано
  • Запрос на удаление, что нём не так?

    @Akina
    А ошибку нам предлагается угадать? ПОЛНЫЙ текст ошибки, от первого до последнего символа - в текст вопроса.

    PS. Сам запрос синтаксически и логически верен.
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Дмитрий Беляев,
    насчет второго варианта, он ещё и денормализован

    ??? Почему? что тут денормализованного?
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Но это, как написали, денормализованный.

    Ну и неправильно написали. Нет там ничего денормализованного. Обычная себе разреженная таблица.
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    Andrey, Вы прочитали материалы по ссылке в постскриптуме?

    Не надо рассказывать, как вы пытаетесь решить задачу - расскажите саму задачу. Конкретно и предметно. Пока, судя по описанию, вы используете какой-то сторонний ЯП с каким-то сторонним фреймворком, который даже не подозревает о существовании триггеров и неспособен их работу правильно учитывать. Вы же упорно намерены триггеры в эту систему втащить, и по итогу боретесь с системными косяками своего инструмента. А сова не натягивается...
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    Вы можете создать максимально упрощённую, но при этом адекватную, модель? CREATE TABLE для трёх связанных таблиц (только нужные для вопроса поля, только PK/FK, всё лишнее поудалять), INSERT INTO, вставляющий в них по 3-5 связанных записей, затем обсуждаемый UPDATE в одну таблицу, описание того, что должно при этом измениться в остальных двух таблицах (и подробно - почему именно так), плюс требуемое финальное состояние данных в каждой из трёх таблиц.

    идея в том что при UPDATE я беру данные из данного UPDATE и вношу их INSERT INTO в другие таблицы чтобы на выходе у пользователя уже подтянулись сгенереные данные. А не закрывать и открывать снова "окошко".

    Не понял.. вроде раньше было сказано:
    чтобы когда пользователь нажал "создать объект" в этом ПО - ему сразу вываливался на экране этот созданный объект с уже вставленными данными этим тригером.

    Судя по тому, что ты описываешь - твоё ПО то ли вообще не знает о существовании двух дополнительных таблиц, то ли никак их не связывает с создаваемым объектом. Но раз так - то изменения в тех двух таблицах вообще не должны менять поведения этого ПО.
    Ну и непонятно, как ты собираешься создавать НОВЫЙ объект запросом UPDATE.
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    триггер, который перед UPDATE таблицы вносит данные в другие таблицы.

    Глупо. Лучше сперва убедиться, что вставка прошла нормально, и только потом изменять другие таблицы - тогда при проблемах не придётся откатываться.

    Исключение - если на эти самые добавленные в другие таблице записи должна ссылаться вставляемая запись. Но тогда это свидетельствует о грубых косяках в схеме данных.
    Написано
  • Как исключить при join повторение множества для другого множества?

    @Akina
    Есть 2 таблицы

    Дайте их в виде проверенно рабочих CREATE TABLE + INSERT INTO.

    PS. Задача-то в общем плёвая. UNNEST второй таблицы. Нумерация в группе по буковке в обеих таблицах. LEFT JOIN. Обратная агрегация.
    Написано
  • Как лучше хранить и быстро искать связанные данные?

    @Akina
    Таблица групп.
    Таблица терминов.
    Таблица, связывающая термин и группу, с полями даты начала и конца валидности связи. Для актуальной связи конец - в далёком будущем.
    А, собственно, всё.
    Разве что ещё мелочь - при расщеплении группы в новую группу выделяется меньшая подгруппа терминов, а если равно - то любая.
    Написано
  • Как гарантировать последовательную запись данных без пропусков id?

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