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

Ну начали письками меряться. Мой "суррогат" является стандартом для хранения данных. Твоя поделка на коленке будет глючить и в твое отсутствие ее выкинут нахрен. Потому что никто не понимает, как это чудо работает и где какие триггеры заныканы.

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

всеми аспектами скл-сервера на базе твоих бинов

Чеееем? Надеюсь термин "аспект" ты применил в литературном стиле, а "скл-" это не сильно обидное ругательство

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

Судя по таблице заказ только с одним клиентом связан. customer_id в Order надо.

Да, точно! Упустил :)

Мне вот кажется, что достаточно будет и 3х таблиц.

Вполне возможно :) Покажи свое решение ;)

ВСЕ, что не стояло в техзадании это действительно не моя головная боль.

-----

Ну в тех.задание тебе создание триггера вписали - в этом проблемы нет.

А вот инструментария для его создания у тебя нет. И это - головная боль.

Потому что никто не понимает

-----

Интересно девки пляшут...

Кто-то разрабатывал СУБД, делал возможность в определенной ситуации использовать функционал написанный прогером, а тут пришел Кодер и говорит - то, что написано, никто не понимает...

Я, как человек доверчивый, поверил бы, но...

...мешает то, что в группу тех кто поленился освоить триггеры Я не попал.

Это Я еще не стал оценивать Жабу с точки зрения одной буржуазной лженауки...

А не от задачи.

-----

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

Спляши, плс, от задачки...

И задачка - не единственная, которая не укладывается...

А вот инструментария для его создания у тебя нет. И это - головная боль.

Упс, Сколько времени займет добавление триггера в готовую базу?

делал возможность в определенной ситуации

Именно так. Разумеется есть специфичные задачи. Но это исключение из правил и редкий случай. А в стандартной ситуации (типичное сохранение данных в базу) нужно использовать стандартные средства. А когда начинаются "определенные ситуации" на уровне базы начинается жопа при отлове багов. Ибо ВДРУГ сохранение начинает "в определенных ситуациях" работать не стандартно.

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

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

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

Покажи свое решение

Ну надо вначале, хоть как то пояснить как к нему прийти. И без дополнительных уточнений уже не обойтись.

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

Дальше нужно будет решить, что делать с количеством отдельных заказов. Так как их не предполагается иметь больше трёх решаем иметь для каждого заказа отдельную строку. Если бы кофе приходило на склад десятками или сотнями, то нужно было создать колонку "количество".

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

В итоге получилось следующее:

Ну очевидно, что твое решение не позволяет казывать несколько чашек кофе.

Посмотри на картинку:

Тут есть возможность включить в заказ не только заказать несколько чашек одного сорта кофе, но можно еще заказать все 3 сорта кофе одновременно.

Так что твое решение не покрывает заданную тобой таблицу.

Ну, вообще-то позволяет. Приглядись к Клаусам за 5 и 6 число. Их стало 2 и 3 соответственно.

А вот что сломалось так это количество "счетов" (laufendе Nummer теперь не от 1 до 6)

но можно еще заказать все 3 сорта кофе одновременно

Вот только удаление данных из таблицы "сортов кофе" лучше запретить.

Чой-та? Разрешаем удалять если не используется. ON DELETE RESTRICT

А ещё тут спряталась гадкая штука... А что мы будем делать когда цену кофе поменять надо будет? Если старые счета ссылаются на запись, и не хранят цену сами, то они внезапно изменятся. И окажется что клаус 5-го числа не 7.40 заплатил, а 8.60.

Чой-та? Разрешаем удалять если не используется.

Ну и как это всё сейчас объяснить? - ON DELETE RESTRICT и прочее...

А ещё тут спряталась гадкая штука...

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

Ну и как это всё сейчас объяснить? - ON DELETE RESTRICT и прочее..

Ну так же как и "почему нельзя удалять". Но да, согласен, проще сказать что запретим удаление, чтобы не сломать табличку.

Решаем пока эту проблему игнорировать

Ой. Невнимательно читал.

Ну так это же не эквивалент :) получилось по одному счету на каждый кофе. Это отличается от того, что было задано в условии ;

это 4 разных счета ;)

Бухгалтер не будет рад такому решению ;)

Упс, Сколько времени займет добавление триггера в готовую базу?

-----

Так ведь при твоем подходе - до бесконечности - у тебя просто нет такой возможности.

А в стандартной ситуации

-----

А у нас точно стандартная ситуация?

А если не стандартная, то сразу появится возможность создать триггер в базе?

Проблема не в задаче

-----

Ну значит нет никакой проблемы получить решение!!!

Тебе скинуть бины которые подойдут для задачи или сам набросаешь?

Потом в 10 секунд сбросишь в базу... и у меня пропадет головная боль по этому моменту.

Не укладывается ваше решение этой задачи.

-----

Предложи другое.

Задача простая: тематический каталог, группировка какой-то информации по каким-то темам, добавление, получение, разделение и т.п.

Все - тривиально. Все - понятно. Все - описано.

Вот только ни одной толковой имплементации пока не нашел.

Бухгалтер не будет рад такому решению

Уж до кого нам нет дела, так это точно до бухгалтера

Нету тама бухгалтера, есть только официант.

Зато хорошо видно, сколько может быть проблем для казалось бы простой задачи.

Это всё к тому, что могут дать курсы. В лучшем случае это:

https://siblec.ru/informatika-i-vychislitelnaya-tekhnika/b...

А всё остальное нужно уже думать/изучать самому. Хотя многие проблемы будут видны только с опытом.

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

Если старые счета ссылаются на запись, и не хранят цену сами, то они внезапно изменятся. И окажется что клаус 5-го числа не 7.40 заплатил, а 8.60.

Неудобно и не всегда возможно. Я покупаю кофе. Выбираю товар из списка. А откуда возьмётся цена? При каждой покупке с бумажки вручную забивать? На самом деле это можно сделать 2-мя способами. Кофе имеет цену. И покупка имеет стоимость, которую она получает от кофе в момент покупки. Тогда при изменении стоимости кофе стоимость покупки не меняется. Или при изменении цены на кофе просто закладывать новый товар.

Или при изменении цены

-----

В таблицу Цены вносится запись об новой цене. "Старые цены" - никогда не изменяются и не удаляются.

Кстати - цена действует от установленной даты до... установленной даты. Ну так в тех.задании определили "периодичность" изменения цены. Т.е. при установке новой цены нужно внести изменения в запись об предыдущей цене - до... установленной даты - поменять.

Как менять будешь? Транзакцией с двумя-тремя запросами или повесишь триггер на табличку? Если вдруг триггер - то как ты его туда по твоей методике повесишь?

В таблицу Цены вносится запись об новой цене.

Пока такой таблицы не было. Но да. Так лучше. Если нет партий товара с фиксированной ценой.

Как менять будешь?

Никак. Есть класс "кофе". Если подгрузка цены автоматическая, то при создании обьекта класса он получит цену по алгоритму(последнюю или по дате или по дню недели или прямым пользовательским выбором из списка итд). При создании обьекта класса "закупка" этот обьект тоже получит ссылку на обьект класса "цена". То есть цена есть и у кофе и у закупки. При изменении цены у кофе предыдущие закупки свои цены не меняют - привязка не через товар, а прямая.

И эта операция это логика на уровне программы. База данных просто хранит обьекты и обеспечивает целостность информации, не давая, например, удалить задействованные цены.

Никак.

-----

Никак - не пойдет.

По условию - на каждый момент времени имеется одна цена.

Поэтому при изменении цены требуются две операции:

- добавить запись с новой ценой и периодом применения

и

- изменить верхний предел применения в старой цене.

Вопрос лишь в том каким инструментом это делать.

и обеспечивает целостность информации

-----

Вот и обеспечивай - у тебя не явный констрайнт на недопустимость двух цен в одном периоде.

Можно, конечно, считать каждый раз, но это куда проблемнее триггера на таблице.