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

Маска программы для импорта или внесения новой цены. Это никаким образом не влияет на существующие классы. И на сохраненные объекты.

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

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

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

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

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

Согласен, на бухгалтера плевать. А вот на то, что с твоей структурой данных нельзя получить таблицу из задания не наплевать ;) Так что сори, но твоё решение не годится 😀

И можно иметь несколько цен

-----

Это не меняет ситуацию.

выберет нужную цену согласно алгоритма

-----

Какова "цена" работы "алгоритма"?

Кто сказал, что не может быть несколько цен на один товар в одном периоде?

-----

Я сказал. Упростил для понимания.

Хочешь несколько - дополнительный ключ в таблицу и... снова пункт 1. - триггер или код в аппe...

А вот на то, что с твоей структурой данных нельзя получить таблицу из задания

Что конкретно нельзя получить?

Всё что там есть - это то, что определённый клиент имеет несколько заказов в определенный день.

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

Какова "цена" работы "алгоритма"?

Сколько стоит подгрузить 3 записи из базы данных и дать бухгалтеру список для принятия решения? Сколько стоит загрузить ПОСЛЕДНЮЮ внесенную запись?

Хочешь несколько - дополнительный ключ в таблицу и... снова пункт 1. - триггер

Да причем здесь триггер? Триггер реагирует на событие и манипулирует записями в базе данных. Здесь нормальное управление записями. Производится из проги. Нафига здесь триггер, когда мы просто из нормальной маски программы закладываем новую цену?

Сколько стоит загрузить ПОСЛЕДНЮЮ внесенную запись?

-----

Неправильная постановка вопроса.

Правильная - Сколько стоит загрузить запись об цене на конкретную дату?

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

Производится из проги.

-----

Можно. Но будет - дороже.

когда мы просто

-----

Да-да... в общем - напиши два решения - твое, а потом - с триггером.

Потом сравни чего и сколько там есть.

Правильная - Сколько стоит загрузить запись об цене на конкретную дату?

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

Записи сначала фильтруются по товару. Это индексируемое поле. Потом остаётся столько записей, сколько было изменения цен на товар. Сколько это может быть? Пара? Пара сотен?

Можно. Но будет - дороже.

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

Сколько это может быть?

-----

Много.

У нас, на небольшом производстве, объем базы превышал 20 гиг...

И, кстати, была проблема с расписанием смен - точно такая же, как с ценами и ценниками...

Сегодня одна, а завтра вдруг другая.

-----

Именно так оно и работает.

Вчера была одна, на сегодня задана другая, а с завтра и до следующего изменения - определена третья.

И никто не видит, как втихоря данные подменяет триггер.

-----

А кто должен видеть?

Ты же говорил - база должна оставаться в порядке. Вот триггер об этом и позаботился.

То, что кодер не знает и не понимает, что база, по природе, слегка более сложное образование чем то, что создается сбросом бинов за 10 секунд - понятно и можно считать - нормально.

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

Это отвратительный стиль программирования.

-----

Отвратительный стиль программирования - использование техников-кодировщиков на месте инженеров-программистов.

Грамотное использование имеющихся инструментов - вполне нормальное явление.

У нас, на небольшом производстве, объем базы превышал 20 гиг.

Мурр, ну ты понимаешь разницу между базой данных и списком цен к одному товару? Ну меняй их 2 раза в день, 10 лет - 10000 записей. Найти последнюю это смешная задача.

вот то, что он роет код и не смотрит в доки где прописано "заполняется триггером" и не

Ты никогда не правил баги? У меня их десятки в день и я разумеется посмотрю в доках. Если в коде не найду. Только в хорошем коде я найду проблему сразу. Класс ентити персистентного слоя или клас репозитори.. Не через полчаса, а вот просто открою соответствующий класс и СРАЗУ увижу проблему. Пока ты в не то что доках хоть что нибудь найдешь, а просто доки найдешь.А скорее всего не найдешь. Куча задокументировано мусора это тем не менее куча. Чем больше слепленных на коленке хреней, тем больше доку. Я слышал, у тебя часто тупая молодежь не справляется? Наверно не успевает доки дочитать? 😁

использование техников-кодировщиков на месте инженеров-программистов.

😁

Всё что там есть - это то, что определённый клиент имеет несколько заказов в определенный день.

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

между базой данных и списком цен

-----

Все необходимое имеется в исходной таблице.

Только вот из нее просят сделать нормальную базу...

Только в хорошем коде я найду проблему сразу.

-----

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

Чем больше слепленных на коленке

-----

База, сброшенная из персистентного слоя как раз относится к разряду слепленных на коленке.

Ее единственное преимущество - можно использовать кодеров не имеющих знаний по базам данных.

у тебя часто тупая молодежь не справляется?

-----

Не часто, а регулярно. Их просто недоучивают под мои задачи.

Именно поэтому Я редко рекомендую кому-то в возрасте начинать вползать в ИТ - изучать - много, будут сидеть на равных с туповатыми недоучками.

невозможность заказать больше одной чашки за один раз

Ну это тоже твоя интерпретация

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

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

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

Так что в итоге получилось следующее

Еще правда забыли подискутировать отчего названия на немецком, а не на английском, отчего KundeId, а не kunde_id, названия таблиц в множественном, а не в единственном числе и пр.

Поверь - в хорошем коде, т.е. в коде который базируется на теории которую ты не изучил

Такого кода не существует. Мы ж говорим о нормальной фирме, не о партизанском отряде? Это значит, что самодеятельноe введение новых технологий категорически запрещено, а введение сопровождается ОБЯЗАТЕЛьНЫМ обучением команды. Упс

База, сброшенная из персистентного слоя как раз относится к разряду слепленных на коленке.

Мурр, тебя начинает нести. В чем смысл обругивать стандартные классические библиотеки, перенесшие сотни релизов и протестованные миллионами програмистов?

Не часто, а регулярно. Их просто недоучивают под мои задачи.

Честно, это показатель. Когда люди регулярно недопонимают какие-то задачи, я бы серьезно задумался, а виноваты ли в этом люди. Или все-таки задачи.

Я еще не видел человека, который не смог бы разобраться с построением стандартного веб-приложения на спринге. Простого, надежного, стабильного и быстрого.

Получилось хорошо.

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

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

А вот если бы мы начинали c задания, такой проблемы бы не возникло.

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

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

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

А вот рассказать дальше, что делать - это пожалуй нужно.

Итак, то что мы получили выглядит гораздо лучше исходного варианта, но где же тут база данных?

Можно, конечно продолжить все в эксель, но это явно не наш путь.

Для "нормальной" реляционной базы данных, типа - MySQL, Ms SQL Server, Oracle, PostgreSQL, SQLite и пр. нам понадобится создать базу данных, создать таблицы и наполнить их какими либо данными.

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

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

Также нам надо будет определить индексы для таблиц и как таблицы соединяются между собой.

Проще всего сделать модель базы данных в специальной программе, как например

https://www.devart.com/entitydeveloper/

И разрешить ей создать базу данных на основе модели.

Программа бесплатная, если у вас меньше 10 таблиц. Для большего количества нужно уже иметь что-то платное от этой фирмы (например dotConnect for SQLite)

В этом случае модель может выглядеть следующим образом

Стрелочки показывают так называемые отношения (relation), а надписи 1 *, говорят о том что одна запись из таблицы клиентов, может повторятся много раз в таблице заказов.

Данная программа может также создавать программный код описывающий базу данных.

Фубля. И у этих стрелочки не в ту сторону. Да и "Crow Foot" как-то привычнее.

Это я только про диаграмму.

"Crow Foot" как-то привычнее

Кому как

Для меня это просто ужос

сопровождается ОБЯЗАТЕЛьНЫМ обучением команды.

-----

А что КОМАНДА делала в униках?

В чем смысл

-----

Не знаю.

Есть - рутина - пишешь стандарт и будь доволен.

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

По твоему вопросу - что делали такие же миллионы базовиков когда кодеры создавали базы доступным им способом?

Я еще не видел

-----

Посмотри на Кота. Посмотрел? Теперь ты видел того кто не разобрался в реализацией одного веб-приложения.

Где-то пару лет назад искал готовый форум реализованный на шарпе. Форум - нашел, работать - заставил. Как реализовано - не понял.

Просто не хватило времени на изучение того что использовалось.

А что КОМАНДА делала в униках?

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

По твоему вопросу - что делали такие же миллионы базовиков когда кодеры создавали базы доступным им способом?

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

С сущностями на уровне классов проще моделировать. Берем покупателя. Никому и в голову не придет покупателю добавить цену. То есть сущность сразу на этапе моделирования интуитивно понятна. Есть товар. И есть закупка. Мы не скидываем все в кучу и не делим потом "а это поле куда?", нормализуя таблицы. Мы просто описываем процесс закупки.

Теперь ты видел того кто не разобрался в реализацией одного веб-приложения.

В контексте дисскуссии я бы так откыто этим тезисом не размахивал. Но я промолчу

Базы данных учила.

-----

И таки никто так и не дошел до триггеров?

Странно... меня вот не учили, а откуда-то оно у меня есть...

семинары для всех.

-----

Хорошо. Но не заменяет...

С сущностями на уровне классов проще моделировать.

-----

Блин...

В Ентити реализованы ДВА подхода.

Хочешь - лепишь код и по коду сбрасываешь базу.

Хочешь - лепишь базу и по ней строишь код.

При сбросе базы из кода одни ограничения, при лепке кода из базы - другие.

Но! При лепке кода из базы ограничений меньше.

То есть сущность сразу на этапе моделирования интуитивно понятна.

-----

Тебе что-то мешает реализовать сущность в виде таблицы?

Бин и его дефолтное пустое расширение лепятся и поддерживаются автоматом.

В контексте дисскуссии

-----

Именно в контексте - недоизучал, не хватило времени... недоучка в той области.