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

Вначале задача в том виде, как рассказали по телефону. Я ее протестировал на "кошках" - решают без каких либо проблем, в общем виде.

1. Есть террариум в котором нужно поддерживать постоянную заданную температуру, для этого есть функции "ВключитьНагрев", "ОтключитьНагрев".

Требуется вначале построить Flussdiagram, а потом уже прогу на питоне.

Для начала попробуйте просто описать алгоритм используя конструкции "Делай ..." и "Если ... То... Иначе..."

Специально написал немного меньше чем надо. Допишите сами чего еще не достаёт для постновки задачи.

Я вот как бы ни разу не программист но что-то мне подсказывает что должна быть ещё и функция измерить температуру, не?

Выкладывайте свои ответы - обсудим.

А если не будут обсуждать, а будут смеятся над ответом, или пойдут ироничные или саркастические шутки?

Смотря какой террариум. Если он большой, то я предпологаю что в террариуме должно находится несколько датчиков температуры, а так-же несколько подогревательных элементов, допустим по бокам, и посередине. Ведь в квартире иногда бывают 2 или 3 обогревателя, но в константу MAX_COUNT_SENSORS можно просто установить значение 1, тогда будет от одного датчика проверяться. И если это проект для ардуино, то датчики будут возвращать скорей всего числа с плавоющей точкой, что-то вроде около нуля, а range в Python отказывается иметь дело с float, берёт только целые числа. Причём датчики ардуино, будут давать погрешность, калибровка датчиков (термометров) это тот ещё геморрой. А MicroPython какой-нибудь урезаный, там нет прям таких крутых библиотек как в нормальном Python 3.x

Требуется вначале построить Flussdiagram, а потом уже прогу на питоне.

Ох, а мне вот проще наоборот.

"Делай ..." и "Если ... То... Иначе..."

А мне больше нравится использовать ...in range...

 if avg_temp in range(MIN, MED):
...
elif avg_temp in range(MED, MAX):
...
elif avg_temp > MAX:
...
else:
...

Начну с кода, а завтра попробую Flussdiagram нарисовать.

import random 
import sys
#Константы--------------
MIN_TEMP = 0           #Минимальная температура
MED_TEMP = 5           #Средняя температура
MAX_TEMP = 10          #Максимальная температура
STEP = 1               #Шаг
MAX_COUNT_SENSORS = 5  #Максимальное количество сенсоров
#Функци-----------------
#Поиск среднего значения
def avg(items):
  return sum(items) / len(items)
#Делаем теплее
def make_warm(i, idx):
  #Инкрементация массива idx индекса i, на один шаг, с шагом STEP
  i[idx] += STEP
#Делаем холоднее
def make_cold(i, idx):
  #Декрементация массива idx индекс i, на один шаг, с шагом STEP
  i[idx] -= STEP
#Остужаем всё
def make_cold_all(i):
  #Декрементация всех элеметнов массива i, с шагом STEP
  for x in i:
    i[i.index(x)] -= STEP
#Сброс
def restart_all(mv, i):
  #Устанавливаем для каждого элемента массива i, значение mv
  for x in i:
    i[i.index(x)] = mv
#Начало-----------------
#Инициализация переменных
temp = []           # Массив со значением от датчиков
index = 0           # Индекс
avg_temp = 0        # Средняя температура
cmd = ''            # Команда, Y-дальше мониторить/A-выключить подогрев/N-выход
times = 0           # Сколько раз убавлять температуру

#Инициализация 
#temp = [1, 3, 4, 5, 10]
#Главная программа------
try:
    #Рандомно генерируем температуру
    for i in range(MAX_COUNT_SENSORS):
      temp.append(random.randint(MIN_TEMP, MAX_TEMP))
    while True:
      #Получаем среднее значение
      avg_temp = avg(temp)
      if avg_temp != None:
        avg_temp = round(avg(temp))
        #Выдаём все значения температуры
        for i in temp:
          print(i)
        #Перенос на новую строку
        print('')
        #Среднее значение 
        print(avg_temp)
        #Если среднее значение находится между минимальной и средней температуры, то:
        if avg_temp in range(MIN_TEMP, MED_TEMP):
          #Холодно
          print('Холодно, включаю подогреватель')
          #Получаем индекс массива минимальной температуры
          index = temp.index(min(temp))
          #Подогреваем
          make_warm(temp, index)
        #Если среднее значение находится между средней и максимальной температуры, то
        elif avg_temp in range(MED_TEMP, MAX_TEMP):
          print('Нормальная температура, отключаю подогреватель')
          #Понижаем температуру
          make_cold_all(temp)
        #Если температура выше максимальной температуры, то
        elif avg_temp >= MAX_TEMP:
          print('Жарко, отключаю подогреватель')
          #Понижаем температуру
          index = temp.index(max(temp))
          make_cold(temp, index)
        #Иначе ошибка   
        else:
          print('Ошибка, датчики температуры сбрасываются на минимальную температуру')
          #Сбрасывем температуру, до минимального значения 
          restart_all(MIN_TEMP, temp)
      #Спрашиваем, что делать дальше, Y-дальше, A-выключить подогрев, N-нет
      cmd = input('Дальше (Y-да/A-выключить подогрев/N-нет)?').upper()  
      #Если нажали на клавишу N, то завершаем программу
      if cmd == 'N':
        break
      #Если нажали на клавишу A, то отключаем подогрев
      elif cmd == 'A':
        try:
          #Пытаемся выключить на n-раз
          times = int(input('На сколько выключить?'))
        except Exception as err:
          print('Ошибка ', err)
        else:
          #остужаем n-раз
          for _ in range(0, times):
            make_cold_all(temp)
except Exception as err:
    print('Ошибка ', err)

В данной ситуации, т.е. в этом алгоритме выше MED_TEMP не поднимается, поэтому в данном алгоритме, т.е. строка elif avg_temp in range(MED, MAX): бесполезна.

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

ну я надеюсь, что не будут. Все же тема обучение и начинающие.

Хотя иногда бывает действительно сложно удержаться.

А мне больше нравится использовать

В институте как и на работе - делаешь не так как нравится, а так как хотят.

Код пока не смотрел, слишком много. Там должно быть весьма немного. И пожалуйста, длинные простыни в приложение.

Смотря какой террариум

Это нужно узнавать ДО начала работы. Но в принципе не интересует, так как уже есть функции включить подогрев и выключить.

И если это проект для ардуино

Для данного этапа подобные мелочи не интересуют в принципе. Это всё на потом когда будет понимание проблем.

Ну и Вы вроде не такой уж и начинающий

что должна быть ещё и функция измерить температуру

Во правильно. Нам нужны еще исходные данные.

Есть температура заданная (Tsoll) и есть температура измеренная (Tist). Для них есть тоже готовые функции.

или пойдут ироничные или саркастические шутки?

-----

Так обязательно пойдут.

Бо, это не то что сказано, а то как воспринято.

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

А мне больше нравится использовать ...in range...

-----

А мне - когда код выполняет обработку данных.

калибровка датчиков (термометров) это тот ещё геморрой.

-----

Угу... а представь себе, что помимо просто калибровки еще надо учитывать нелинейность самого датчика...

И что датчиков не 1-2, а пара сотен на каждом блоке, а блоков может быть... много.

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

А ты уже и забыл что, где и как у тебя соспагетчено...

НП.

Если взять из жизни... можно составить примерный алгоритм, допустим если тело человека ниже 32 градусов, то можно сказать это мертвец, если же выше 41, то тоже мертвец, т.к. белки начинают сварачивается. Если выше 38 дают таблетки, а если ниже 32, то будет скорей всего какая-нибудь диагностика. значения констант MIN_TEMP, MED_TEMP, и MAX_TEMP зависят от того, смотря кто в террариуме живёт. Я думаю что в промежутки MIN_TEMP и MED_TEMP нужно включать обогрев, а если выше MED_TEMP отключать. калибровка датчиков это геморрой, а значения температуры от датчиков скорей всего будет очень маленьким 0.000...

для этого есть функции "ВключитьНагрев", "ОтключитьНагрев".

-----

Для веселости - в имплементации функций допущена ошибка - повторный вызов сделает инверсную операцию...

смотря кто в террариуме живёт

-----

Отсюда примерно полшага до понимания того, что житель террариума может меняться.

Не-а. Так нельзя. При учебных задачах надо исходить из того, что всё работает идеально, если не оговорено иначе. А то любую задачу можно своими выдумками усложнить до бесконечности.

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

Если взять из жизни..

Нету тута у нас никой жизни, только сферические кони в вакуме

Жизня будет на работе.

Вот структограмма, рисовал её этой программой https://www.struktograf.de/, температура сначало повышается до 37, потом понижается до 34, и так туда сюда прыгает в диапазоне 34..37 градусов...:

Правда сначало накалякал код на vb6, потом превратил в структограмму, завтра на Python переделаю...:

Private temp As Integer
Private cmd As Integer
Private c As Long
Private Const MIN_TEMP = 34
Private Const MAX_TEMP = 38

Private Sub Form_Load()
  i = 0
  cmd = 0
  c = Me.BackColor 
  Me.Timer1.Enabled = True
  Me.Timer1.Interval = 100  
End Sub

Private Sub Timer1_Timer()
    Me.Caption = i
    If cmd = 0 Then
        i = i + 1
        If i > MAX_TEMP Then
            Me.BackColor = vbRed
            cmd = 1
        End If
    ElseIf cmd = 1 Then
        i = i - 1
        If i < MIN_TEMP Then
            Me.BackColor = c
            cmd = 0
        End If
    End If
End Sub

При учебных задачах надо исходить из того...

-----

...чему требуется научить.

АлехНек пока не сформулировал какая будет цель обучения.

Можно предположить - не программа регулирования температуры в террариуме - это только средство.

А что если...

-----

Корректным ответом будет машина состояний.

Полная. Или дополненная фиктивным состоянием до полной.

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

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

Ну а что можно сделать в форуме в одной ветке?

Просто немного показать, что такое программирование и с чем его едят.

Немножко чему то научится.

К сожалению, приходится не только хвалить но и ругать.

Замечательный пример, как НЕ нужно писать программы.

Вот перлы, которые ну никак не предполагались при описании задачи

Рандомно генерируем температуру
Получаем среднее значение
Получаем индекс массива минимальной температуры
Иначе ошибка
Спрашиваем, что делать дальше, Y-дальше, A-выключить подогрев, N-нет

Ну не нужно из пушки палить по воробьям

Вот структограмма

Я только хочу спросить где в задании это было написано?

Ну и дополнительно: откуда взялась максимальная, минимальная температура и какие то команды?

Что правильно, ссылка чем делалось

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

тоже задачки кидать

Хорошее решение, только номер не забудьте им дать. И отвечающий тоже должен номер задачи написать к чему ответ.

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

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

Ну а что можно сделать в форуме в одной ветке?

-----

Вообще-то, много чего.

Например, можно запостить полного Страуструпа и свои комментарии к каждой его сентенции.

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

-----

Опять таки - данное не может быть целью так как является средством.

Ну и как средство оно зависит от того к кому применяется.

Мне вот насколько будет полезно? Угу...

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

А для тех кто не понимает - для них тоже бесполезно - им надо объяснять что такое Если...то...иначе... и зачем оно надо, и как из него построить заданное.

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

Немножко чему то научится.

-----

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

При этом нужно дополнительно контролировать усвоенность и применение элементов изученных ранее.

Тогда можно чему то научить.

Ну и дополнительно: откуда взялась максимальная, минимальная температура и какие то команды?

Допустим минимальная температура 20, максимальная 35. Датчик в реальном времени измеряет температуру, а дальше программа обращается к шине данных, там из аналога переводится в цифровое значение, и программа получает значение ввиде каких-то чисел. Если температура 18, то включается подогрев, как достигает в террариуме значение 35, подогрев отключается. А cmd = 0 включает подогрев и мериет температуру, cmd = 1 отключает подогрев, но продолжает дальше мерить температуру, и снижает температуру. Покуда это симулятор, мы симулируем датчик температуры, и подогрев. Если бы это был бы не симулятор, то вместо cmd мы бы назвали бы heater, и он принимал бы булевое значение, если бы температура была бы ниже минимума, то программа бы устанавлива heater = true, и дальше мерила бы температуру. Всё просто:

 //Константы
МАКСИМЛЬНАЯ_ТЕМПЕРАТУРА = 35
МИНИМАЛЬНАЯ_ТЕМПЕРАТУРА = 18

//Инициализация
текущая_температура = 0
обогреватель = выкл

// Цикл
циклить пока True:
  текущая_температура = получить_текущую_температуру()
  запуск_обогревателя(обогреватель)
  если текущая_температура > МАКСИМЛЬНАЯ_ТЕМПЕРАТУРА то:
    обогреватель = выкл.
  если текущая_температура < МИНИМАЛЬНАЯ_ТЕМПЕРАТУРА то:
    обогреватель = вкл.

А если несколько датчиков температуры и несколько подогревов, то можно вынести это в функцию... или можно даже использовать мистер Фред. В данном алгоритме попахивает многозадачностью, я бы в данном проекте попытался бы использовать бы FreeRTOS это легковесная многозадачная ОС реального времени для IoT.

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

Вот Flussdiagramm:

Пардон, там ошибки, вместо "35 градусов", ">35 градусов", а вместо "18 градусов", "<18 градусов".

Для начала попробуйте просто описать алгоритм используя конструкции "Делай ..." и "Если ... То... Иначе

наверное перед тем, как что-то программировать, правильно было бы почитать про PID контроллер, хотя бы в википедии. Там и теория есть, и свойства решения, и как это можно имплементировать. Кстати, в arduino под это есть аж целая PID Library.

Знакомый в Уни, начал подкидывать задачки.

а я бы добавил задачки от другого профессора, которые он публикует на bwinf.de - там выбор побольше будет, а если взять второй тур и все предыдущие годы, то на несколько лет можно чадо по самое здрасте загрузить, да и самому порадоваться за красиво поставленные задачи.

Может быть я что-то не так понял (и уж точно я не знаю питон :) ), но мне кажется, что ты пытаешься решить задачу "в лоб" :)

Я понимаю, что задача настолько просто сформулирована, что "в лоб" решить ее гораздо проще ;)

Но все таки мне кажется, что тут нужно сделать 2 класса:

1) Контроллер градуcника

2) Контроллер обогревателя

Контроллер градусника должен посылать сообщения контроллеру обогревателя.

Таким образом логика контроллера обогревателя становится максимально примитивной и, что важно, тестируемой:

public interface ITermometerController 
{
   event EventHandler<TemperatureEventArgs> Temperature;
}

public class TemperatureEventArgs : EventArgs
{
   TemperatureArgs (int value)
   {
     Value = value;
   }
   public int Value {get; private set; }
}

public interface IHeaterController
{
  void HeaterOn ();
  void HeaterOff ();
}

public class HeaterController : IHeaterController
{
  public HeaterController (ITermometerController termometer)
  {
     termometer.Temperature += termometer_Handler;
  }

  public void HeaterOn()
  {
    ...
  }

  public void HeaterOff()
  {
    ...
  }

  public void termometer_Handler(object sender, TemperatureArgs e)
  {
    if (e.Value > highThreshhold)
      HeaterOff();
    else if (e.Value < lowThreshhold)
      HeaterOn();
  }
}

Вот и весь код :)

правильно было бы почитать про PID контроллер

Зачем? Это описание железяк?

termometer.Temperature += termometer_Handler;

А что это значит?

Это подписка на эвенты.

нужно сделать 2 класса

-----

нужно делать 5 классов - градусник, нагреватель, два контроллера и террариум.

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

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

это и будет решение в лоб.

НО! это не будет решением начинающего...

Пыхх... ты так и написал 5-ку...

нужно делать 5 классов - градусник, нагреватель, два контроллера и террариум.

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

Поставленная в 1-ом посте задача сводится к "написать котроллер обогревателя". Все остальное - вода.

НО! это не будет решением начинающего...

Это направление, в котором начинающий должен двигаться, если он хочет чему-то научиться.

Пыхх... ты так и написал 5-ку...

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

Это подписка на эвенты.

Что за язык?

нужно делать 5 классов - градусник, нагреватель, два контроллера и террариум.

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

Что за язык?

C#

Поставленная в 1-ом посте задача сводится к "написать котроллер обогревателя"

-----

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

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

террариум, по определению, должен агрегиривать нагреватель и термометр.

изолируем фактические нагреватель и термометр соответствующими контроллерами.

Вот она - 5-ка.

Можно - усложнить (или упростить сопровождение) введя фабрики для двух сущностей, как оно обычно и бывает на практике.

в котором начинающий должен двигаться

-----

Ну должен. У него, правда, пока еще не уложилось Если...То...Иначе.

Там 2 класса, один из которых не имеет функционала.

-----

А должно быть минимум 3.

Пусть два из них - нагреватель и термометр - абстрактные.

При этом нагреватель не должен знать об термометре, а термометр - об нагревателе.

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

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

И, кстати, у тебя в решении есть существенная ошибка.

Она заключается в том, что ты принял как данное термин - нагреватель.

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

Но не всегда - террариум, по определению, является системой с контролируемой температурой.

Так что вполне может иметь место ситуация когда надо охлаждать - следовательно - надо переделывать контроллер.

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

Не подходит. Там термометр опрашивается в цикле.

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

Аквариум, терариум или жилая комната - в данной задаче это не имеет значения. Это просто описательная информация. Также как в задаче "Ученица 1-ого класса деревенской школы построила себе в лесу шалаш и спрятала там 10 монеток. При этом в своей копилке дома у нее было 16 монеток. Сколько всего монеток было у школьницы?" полно описательной информации, которая ничего не дает. Это просто контекст, который не играет никакой роли в решении.

изолируем фактические нагреватель и термометр соответствующими контроллерами.

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

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

Ну это уже holly war на тему "толстых" и "тонких" контроллеров :)

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

А если прочитать условие задачи, то это будет корректно и для данной задачи :)

Событие приходит от термометра

-----

А кто сказал, что Термометр в состоянии делать нотификацию?

Может или не может - неизвестно - потому термометр и оборачивается в контроллер термометра.

Нагреватель - аналогично.

удав может

-----

Может.

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

И вместо удава там может быть какой-нибудь песец или пингвиn...

Не подходит. Там термометр опрашивается в цикле.

-----

Ну и что? Ну опрашивается, ну в цикле. Заявленному требованию - удовлетворяет - значит годится.

Ну это уже holly war на тему "толстых" и "тонких" контроллеров :)

-----

И тем не менее - если делать правильно - значит делать правильно.

А если прочитать условие задачи

-----

Читаем:

нужно поддерживать постоянную заданную температуру

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

Ну и что? Ну опрашивается, ну в цикле. Заявленному требованию - удовлетворяет - значит годится.

Где я говорил, что это решение не годится? Я сказал, что это решение "в лоб". Ну или если бы писали на ANSI C :)

И тем не менее - если делать правильно - значит делать правильно.

Толстые и тонкие контроллеры - это не вопрос привильно или нет. Спорить тут не имеет смысла.

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

Это потому что ты прочитал только половину условия:

нужно поддерживать постоянную заданную температуру, для этого есть функции "ВключитьНагрев", "ОтключитьНагрев".

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

А кто сказал, что Термометр в состоянии делать нотификацию?

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

Более того, а кто сказал, что обогреватель вообще автоматически может реагировать на изменение температуры? И ВДРУГ, решение Программиста полностью функционирует без переписывания, если в качестве эвента выступает дворник, считывающий температуру и инициирующий события.

Что то тут какое-то недопонимание. Я не спрашивал, что делают данные штуки в вашей программе. Я спрашивал, где это в задании?

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

Вот Flussdiagramm:

Очень похоже, забыли только сказать чем рисовали. Немного неаккуратно и не совсем соответствует DIN 66001

https://de.wikipedia.org/wiki/Programmablaufplan

• yEd Graph Editor – kostenloser Diagrammeditor, mit dem Datenflussdiagramme gezeichnet werden können
• Orinoco – kostenloses Tool zur Modellierung und Simulation von Datenflussdiagrammen

Где я говорил, что это решение не годится?

-----

Ну а зачем писать что-то если удовлетворяющее решение уже есть?

Это потому что ты прочитал только половину условия

-----

Я прочитал как раз то что нужно и прочитал правильно.

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

Почему ты проигнорировал то, что после запятой

-----

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

перед тем, как что-то программировать, правильно было бы почитать про PID контроллер,

Зачем это знать начинающему?

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

Для первого этапа достаточно описать всё хотя бы своими словами. Я удивляюсь почему до сих пор никто ничего не написал из тех кто хочет учится. Ведь именно для и них всё и затеял.

а я бы добавил задачки от другого профессора

Добавляйте. Только я бы в этой теме сделал ограничение: Кто добавляет задачи, тот и ментор для них.

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

Но все таки мне кажется, что тут нужно сделать 2 класса:

Не забывайте задача для начинающих. Никакие классы им неизвестны.

Но это не красиво.

-----

Это вполне красиво - на то он и контроллер, чтобы изолировать сущностный элемент.

Контроллер действительно может долбить термометр регулярно

-----

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

если в качестве эвента выступает дворник

-----

Так ведь без разницы.

Разница появится когда будет требоваться учитывать показания термометра, действия дворника и мнение питона.

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

-----

Потому что в наличии, по факту, не те, кто хочет учится, а лишь те, кто хочет чтобы их научили.

А сии две категории есть весьма различны по факту.

требуется учитывать инерционность тепловых процессов.

Это вы придумали

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

Это вы придумали

инициализировать "регулятор": некая сущность, которая будет имплементировать управление, вычисляя "управляющее воздействие" (напомню, это - две величины: время включенного состояния и пауза после). 0. запросить у регулятора управляющее воздействие
1. выполнить управляющее воздействие2. перейти к 0.

Это вообще с программированием ничего общего не имеет.

постановка задачи.

Ну вот, наконец то, то с чего и нужно начинать. Вначале нужно понять что же действительно хочет пользователь.

А не фантазировать: поддержание температуры в террариуме в заданных пределах (tmin, tmax), требуется учитывать инерционность тепловых процессов и т.п.

Я специально привел вначале самое простое описание - обычно с этого и начинают говорить что надо.

И задача программиста выбить все нужные знания у пользователя.

Что у нас есть на сегодня:

• Температура желательная
• Температура измеренная
• Внешняя функция включить нагреватель.
• Внешняя функция выключить нагреватель.

Что нам еще не хватает?

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

И тут мы подходим к типам данных.

Базовых не так уж и много

символ - 'A', 'B'

строка из символов - "asdfg"

целый тип - 0,1,2,3, -10

вещественный тип: 0.12345, -3.14

логический тип: Да, Нет.

В каждом языке существуют свои особенности определения и использования данных. В том числе и способ их представления в машинной форме. Но этих вопросов мы пока касаться не будем.

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

Хотя бы то, как представлена температура - как строка или как число.

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

uscheswoi_82

написал достаточный алгоритм, который постоянно мониторит температуру и реарирует. Программист написал изящную реализацию, которая реагирует на события. Обе реализации достаточно абстрактны, что бы поднимать дополнительные модули для рассширения функтиональности. Не надо перегружать прогу подробностями, которые могут ВДРУГ понадобится.

Пока ограничимся тем, что температура представлена вещественным числом

-----

Ограничься - целым. Если нужна точность - задай единицу измерения 0.1, 0.01, 0.001 градуса.

Для вещественных тебе придется объяснять представление в виде порядок и мантиса с усечением/округлением - именно то чего ты пока касаться не хочешь.

Это не играет никакой роли в процессе составление алгоритма.

Вообще то играет, потому как 2+2 может быть и 22 и 9 не обязательно меньше 10

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

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

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

почти решенная задачка

Код вообще то интересует в самую последнюю очередь.

И код должен быть в "стиле начинающего".

Мы ещё и с постановкой задачи не определились

Для вещественных тебе придется объяснять представление

Зачем? Это знать совершенно не нужно. Достаточно знать что может быть 20.0, 20.33333, 22.5 и т.п.

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

и не определитесь никогда

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

Да и желающих хоть немного чего узнать, тоже пока не нашлось.

Зачем?

-----

Затем, что есть два вещественных числа - 22.3 и... 22.3... и при этом одно из них меньше другого.

Чтобы объяснить этот момент - придется углубляться в детали представления, а это на уровне Если...То...Иначе - лишнее.

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

Можно перейти и к 2231 и 2233 - по 0.01 градуса - тут уже будет видна причина неравенства 22.3 и 22.3.

я пользователя уже пытал и узнал что он действительно хочет

-----

У тебя есть проблема из 223 нарисовать для пользователя "22.3С"?

Вынеси в отдельную подзадачу и пусть ее реализовывают...

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

К тому же с точки зрения обучения есть еще один момент.

Нужно чтобы юниор учился мыслить абстрактно.

С этой позиции 223 которое более абстрактное значение много предпочтительнее 22.3 которое есть конкретная температура.

Еще раз скажу - сформулируй цель которую пытаешься достичь данным упражнением.

Каждый пытается сам что то додумать.

-----

Ну так ты именно это и просил.

Вообще то играет, потому как 2+2 может быть и 22 и 9 не обязательно меньше 10

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

Не в этом дело. Программист мог класс термометра полностью расписать. Вплоть до краски корпуса. Учитесь абстрагироваться. В градуснике вообще температуры может не быть, а как на термостате, 2 положения, одно для "слишком горячо" и другое для "слишком холодно". Аналоговые движки без единиц измерения.

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

Красивое решение во первых простое. Во вторых масштабируемое. В третьих есть вещи основные и второстепенные. Например блок обработки температуры и принятия решения можно вынести. Тогда без разницы, какую инфу присылает термометр, блок обработки переводит ее в событие.

Я спрашивал, где это в задании?Я спрашивал, где это в задании?

Задание толком не написано, решил действовать сам, и сам всё делать (придумывать концепцию, до имплементации кода). Ну вот чтобы кота за хвост не тянуть, решил перейти из теории в практику... Значит, сделал как написано было в "учебнике", для начинающего электронщика, точнее это https://images-na.ssl-images-amazon.com/images/I/61xObTMZJ...:

Собрал как написано было в книжке, на шину посадил термистор и резистор, но забыл откалибровать, т.е. покрутить переменный резистор (слева):

В итоге показывает неправильно температуру.

Показывает -26°C, хотя в квартире как минимум +25°C градусов есть.

Когда закрываю рукой, хотя она тёплая +36°C, программа почему-то показывает -40°C.

Вот код измерения температуры с формулой:

Private Sub Timer2_Timer()
.  
  ' Die Timer2-Routine zwei wurde am Ende wie folgt erweitert
  ' um den NTC-Widerstand und die Temperatur zu ermitteln
  Dim U_mess_1000 As Single
  Dim R_NTC As Single
  ' OP hat zweifache Verstärkung!
  U_mess_1000 = (il × 2.5 / Val(Me.lb_2_5_Volt.Text)) / 2
  ' Widerstand nach Masse = 1000 Ohm, Spannung daran ist U_mess_1000
  ' U_mess_1000/1000 = U_NTC/R_NTC
  ' U_NTC = 5 Volt -U_mess_1000
  ' R_NTC = U_NTC/U_mess_1000 × 10000 =
  ' R_NTC = (5 V-U_mess_1000) /U_mess_1000 × 1000
  R_NTC = 1000 × (5 –U_mess_1000) / U_mess_1000
  ' Anzeige des NTC Widerstands in kOhm
  Me.lb_R_NTC.Caption = Format(R_NTC / 1000, "0.0") & " K"
  ' Werte aus Tabelle B Wert und R25 Wert
  ' und in Temperatur umrechnen
  Me.lb_temp.Caption = _
  Format(1 / (Log(R_NTC / 4472) / 3977 + 1 / 298) –273, "0") & "°C"
  CloseHandle:
    If FT_Close(lngHandle) <> FT_OK Then
      LoggerList.AddItem "Fehler bei Aufruf: FT_Close"
      Exit Sub
    Else
    End If
.
End Sub

Очень похоже, забыли только сказать чем рисовали. Немного неаккуратно и не совсем соответствует DIN 66001

Dia см. http://dia-installer.de/index.html.de, ею в коледже заставляли рисовать.

Задание толком не написано,

Специально, между прочим. Разделил на две части. Одна, так как сказали по телефону.

И не надо никакой практики.

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

Диа была моей любимой программой раньше. Теперь потихоньку перехожу на yed.

Вот думаю отчего не пишут начинающие, может действительно непонятно

Гляньте здесь: следование и ветвление

https://skobelevserg.jimdofree.com/инф�%B...

Еще раз скажу - сформулируй цель которую пытаешься достичь данным упражнением.

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

Можешь сам сформулировать, если тебе так интересно.

Ну вот например, сюда все постить:

Blogger, Tumblr, Livejournal

https://tilda.cc/de/

https://ru.wix.com/start/sozdat-blog

неинтересно думать на эту тему

-----

Бывает.

Правда непонятно почему при этом жалуешься на отсутствие внимающих...

Диа была моей любимой программой раньше. Теперь потихоньку перехожу на yed.

У меня есть Visio 2000 Enterprise, Visio 2002. А так-же есть Visio 2003 которая входит вместе с Visual Studio 2003 Enterprise Edition. Dia нравится больше чем Visio. Ok потом попробую Yed.

Вот думаю отчего не пишут начинающие, может действительно непонятно

Просто нет толком постановки задачи, да и начинающие скорей всего учат что-нибудь попроще. А с термометром там будет геморрой см. https://youtu.be/BCdCmPXgyYM?t=244, он ведь не в градусах значений возвращает, а там какое-то непонятное число, нужно термистер калибровать, это такой-же геморрой как столик у 3D принтера выравнивать...

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

Это всё мне не нужно, т.к. у меня есть своя BB.

непонятно почему при этом жалуешься

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

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

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

Когда закрываю рукой, хотя она тёплая +36°C, программа почему-то показывает -40°C.

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

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

Так и нужно узнать что именно не хватает.

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

А когда я показал оригинальное задание - сказали что не понимают.

Детали реализации, могут вполне отличатся, но основной алгоритм остается без изменений.

А с термометром там будет геморрой

Это когда нужно будет на работе такое делать, чтобы правильно работало.

А сейчас всё просто - вызывает функцию, получаем температуру.

Задача то ведь совершенно элементарная вместо 2 действий (ЕСЛИ выполнятся условие ТО действие 1 ИНАЧЕ действие 2) нужно сделать 3.

Это всё до чего нужно додуматься.

у меня есть своя BB

Ну так еще лучше, кидай всё на страницу а ссылку сюда.

Я вот пока ответы писал, приходилось каждый раз всё скроллировать с непонятными скринами диалогов.

хотя было валом вопросов как стать программистом

-----

Валом было других вопросов - Кто научит быть программистом?

Кто научит быть программистом?

На это всегда был только один ответ - курсы и только курсы.

Так и нужно узнать что именно не хватает.

Я алгоритм сделал, см. выше. Мы мерием температуру внутри террариума (по логике внизу будет холодней, а вверху теплей), и при определённом промежутке, при котором холодно, и нужно включать нагреватель, и нужно правильно распределять тепло, и промежуток зависит от того, какое животное находится в террариуме. А хороший алгоритм зависит от наблюдений, а там ищете причину-следствия. Как минимум нужно знать на практике что такое конвекция - https://ru.wikipedia.org/wiki/Конв�%..., алгоритм нужно разрабатывать наблюдая террариум допустим спомощью инфракрасной камеры. По мне так только млекопитающим нужна определённая температура, иначе простуда, а гомойотермные животные при низкой темпераре могут просто впасть в спячку, я видел как муха в квартире упала из-за низкой температуры.

Приведу пример насчёт наблюдений: Дома есть мобильный кондиционер на колёсиках, когда мне летом или весной жарко, я его выкатываю, на нём можно задать минимальную температуру, при которой кондиционер будет включаться, как в квартире стало теплее минимальной температуры, так кондиционер автоматически включается, допустим я ставлю +18°C, а в квартире допустим +25°C, через 2 часа он выключается, т.к. думает что +18°C, смотрю на термометр который находится на расстояние в 2 метра, он мне показывает не +18°C, а что-то в районе +22°C. Т.е. радиус всего +18°C ~1 м. Через какое-то время квартира нагревается, мне уже жарко, а кондиционер думает что ещё +18°C.

Ну так еще лучше, кидай всё на страницу а ссылку сюда.

Зачем? Для 3х пользователей только для создания и модерации сообщений, а для всех остальных только для чтения.

НП.

Я сейчас занят, и играюсь в Java, делаю игру таракание бега, козе понятно что s=v*t, но тараканы могут то тормозить или назад возвращаться, там уже в помощь интегралы...

Я алгоритм сделал, см. выше

Если этот, то это совсем не то

https://foren.germany.ru/showmessage.pl?Number=37557463&Bo...

и нужно правильно распределять тепло

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

Ну так еще лучше, кидай всё на страницу а ссылку сюда. - - Зачем?

Можно ссылку и не ставить

Сейчас специально подсчитал, 5 раз нужно было колесико подкручивать.

Валом было других вопросов - Кто научит быть программистом?

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

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

Нужно идти все же дальше. Может потом кто-то еще захочет почитать.

Из того что мы знаем, нам в итоге нужно пойти по трём путям:

1. ничего не делать
2. включить нагрев
3. выключить нагрев

Проблема, как это закинуть в ветвление у которого только два пути?

Довольно просто, нужно сделать два ветвления. Значить у нас должно быть и два условия.

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

Затем нужно проверить, что у нас с текущей (измеренной) температурой, если она меньше заданной то нужно включить нагреватель иначе выключить.

Теперь осталось вспомнить, что мы получаем температуры в виде вещественных чисел. Вроде какая разница целое или вещественное при сравнении? А она есть и следует пока просто поверить на слово и запомнить, что не следует проверять в лоб - А равно Б, если одно из чисел вещественное. Во многих случая, данную рекомендацию или не знают или игнорируют. И всё работает. Однако до некоторого времени, пока не звонит/пишет заказчик и говорит, что у него программа вдруг стала выдавать неверные результаты.

Поэтому правильное сравнение выглядит немного странно |А-Б| < x, где | | означают абсолютное значение, < обозначает меньше, а х - это допуск или точность. Например, если нас интересует расстояние между городами и мы получили два значения, будет ли нас интересовать равны ли они с точностью до метра или нет? А вот когда хотим заказать новую дверь, скорее всего измерим дверной проем с точностью до миллиметра.

В итоге у нас получается следующее описание:

Прочитать измеренную температуру (Tist)
Прочитать/ввести желательную температуру (Tsoll)

ЕСЛИ |Tist - Tsoll|  < Tolerance 
ТО 1. ничего не делать
ИНАЧЕ
  ЕСЛИ Tist < Tsoll
  ТО 2. включить нагреватель
  ИНАЧЕ 3. выключить нагреватель

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

Вот оригинальная задача

Jede Minute wird auf dem Raspberry mit CRON ein Python-Programm gestartet, das wie folgt abläuft:

Zunächst wird die Soll-Temperatur von einem Internet-Webservice gelesen und in der Variablen Tsoll gespeichert.

Dann wird von einem angeschlossenen Sensor die aktuelle Temperatur im Terrarium ausgelesen und in der Variablen Tist gespeichert. Wenn nun Tist<Tsoll-0,5°C, also zu kühl, ist, wird die Heizung eingeschaltet.

Dazu wird ein Unterprogramm mit Namen HeizEIN aufgerufen. Wenn es zu warm ist mit Tist>Tsoll+0,5°C, wird die Heizung mit Aufruf des Unterprogramms HeizAUS ausgeschaltet.

Damit ist das Python Programm am Ende.

В диаграмме некоторые изменения, но основа осталась неизменной

Кто хочет может добавить код на питоне.

курсы и только курсы.

-----

Ну энто - да... есть, правда, ньюансик - не каждые...

Читать и править чужой код.

-----

Эээ...

Не совсем понятно кто это должен делать...

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

очень важна группа

-----

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

И внезапно приходит озарение.

-----

Есть люди которые будут пытаться...

И есть люди которые будут смотреть как пытаются другие...

подразумевается кто-то кто прочитает и поправит

PullRequests. Обязательны для всех, для новичков это не формальность. То есть ВСЕГДА при правильной организации социалистического труда на код перед вливанием в основной репозиторий кто то должен взглянуть.

звонил профессору и просил проконсультировать

Надеюсь ночью? Самые лучшие советы рождаются ночью после внезапного звонка.😁👍

при правильной организации социалистического труда

-----

При правильной организации нуб может сидеть, смотреть и... становится прогером.

Какие тебе ПуллРекуестс? Там же надо кнопарики тыкать и стресс получится если тыкнуть не туда...

Неее, стресс - не нужен, нужно - чтобы научили быть программистом...

Надеюсь ночью?

-----

Не помню.

Помню, что после этого мне сказали - не трать больше времени...

Ну в начале не было задачи, вы хотели чтобы мы на кофейной гуще гадали, я долго думал про Tsoll и Tist... А нужно было так T_soll T_ist в математике именно так, или хотя-бы t_soll, t_ist

Вчера я оптимизировал код, но уже было поздно.... Делал я в PowerPoint-е.

НП.

В Универе у нас было меньше программирования, больше теории, т.е. решали какие-нибудь lim, всякие производные брали, программировали на Turbo Pascal толи версии 5, толи версии 7. В колледже меньше теории, а больше практики, и в сторону СУБД.

Ну в начале не было задачи, вы хотели чтобы мы на кофейной гуще гадали

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

Ну и после всех объяснений диаграмма получилось к совсем другой задаче.

Хотите играть дальше? Мне уже следующую задачку подкинули.

я долго думал про Tsoll и Tist

Отчего? Что тут неясно?

https://foren.germany.ru/showmessage.pl?Number=37568068&Bo...

Прочитать измеренную температуру (Tist)
Прочитать/ввести желательную температуру (Tsoll)

Вчера я оптимизировал код, но уже было поздно

ничего не поздно никто еще код к диаграмме не выставил

для uscheswoi_82

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

2. Есть следующая таблица

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

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

По многочисленным заявкам трудящихся:

"Имеется предприятие по продаже кофе. Оно продает несколько разных сортов кофе. Каждый сорт стоит нетто + накладные расходы(брутто). Имеются клиенты, которые покупают это кофе. Нужно наладить учет продаж и хранение информации в базе данных"

koder (C)

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

-----

Какой базы?

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

Или у тебя "детская задачка" на нормализацию?

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

Какой базы?

а разве это имеет значение? Вот диаграмма выше для какого языка программирование нарисована?

Таблица - уже задана

И ты бы сразу по этой таблице сбацал что-то на оракле, например?

Или у тебя "детская задачка"

А что тут только с 18+ тема?

Если идти академическим путём, то всё уже описано до нас, искать нужное тоже надо учится.

https://info-comp.ru/database-normalization

https://otus.ru/nest/post/1812/

Но если хочешь можешь описать, как сделать что то приличное.

И ты бы сразу по этой таблице сбацал что-то на оракле, например?

-----

Разумеется.

Правда только для версии 11+ - ниже там Ентити не пашет...

Пойми - если не Я проектирую базу - мне пофиг какая она будет.

А в данном случае - Я - не проектирую т.к. таблица уже задана.

то всё уже описано до нас, искать нужное тоже надо учится

-----

Разумеется.

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

А вот так с напрыгу - как раз то что Я написал и будет...

если не Я проектирую базу - мне пофиг какая она будет

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

надо и ставить задачу для обучения

Ну так напиши как надо. Я исходил как бы из реальной жизни. Вот к тебе пришел чел. показал экзель и сказал - хочу базу к этому.

А мне не пофиг,

-----

Хи-хи... а мне пофиг что тебе не пофиг.

Бо, по факту, таблица - задана.

Какая ни есть - она уже определена.

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

-----

Никакого.

Потому нефиг переделывать то, что после переделки пойдет в помойку.

Исключение - практическая учебная задача (ПУЧ).

Но для ПУЧ должно быть четко определено какую часть какой теории данная практика должна закрепить и теория должна быть доступна до начала работы над ПУЧ.

Ну так напиши как надо.

-----

Это - долго... и не нужно.

Достаточно указать какую часть теории надо изучить и использовать или дать ссылки на теорию.

показал экзель и сказал - хочу базу

-----

Ну и?

Вот - КАК ЕСТЬ - так и вколачиваешь в сервер.

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

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

А уж делать на этой основе программу, совсем ужос.

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

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

а юниор, в принципе, не имеет понятия об том что есть какие-то нормальные формы и пока не ознакомится с теорией ему

Юниор теорию знать ДОЛЖЕН. Иначе это не юниор, а ученик. Юниор это работник с отсутствием опытa полностью закончивший обучение. И нормализация баз данных это базовые знания. Они обязательны.

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

А вот это опыт и с ТАКИМ опытом работник считается мидлом

Есть следующая таблица

Что бы вообще начать, нужно понять, что ЭТО? Если мыслить обьектами, то все становится просто. Что мы описываем с помощью этой таблицы? Потребление кофе?

Юниор теорию знать ДОЛЖЕН. Иначе это не юниор, а ученик. Юниор это работник с отсутствием опытa полностью закончивший обучение. И нормализация баз данных это базовые знания. Они обязательны.

Мна... Точно? А слабо сейчас, никуда не глядя, сказать чем, скажем 4NF отличается от 3-й? Единственный встретившийся мне "юниор", который мог отбарабанить эти определения, как программист был... ну... метров на пять под плинтусом.

Ну так напиши как надо. Я исходил как бы из реальной жизни. Вот к тебе пришел чел. показал экзель и сказал - хочу базу к этому.

Про нормализацию другие расскажут. У меня внезапный взгляд с другой стороны: я бы поинтересовался где у этого чела письменные согласия клиентов на обработку и хранение их персональных данных (имя) :) И всегда ли Claus это тот же самый Claus.

A. Ну для реляционной СУБД тут два варианта:

1)Создать таблицу с 3-мя полями, ID - первичный ключ, FIeldName - название поля, Value - значение:

ID | FieldName | Value

типа:

1 | LaufendeNummer | 1

1 | Datum | 01.02.2021

1 | Kundenname | Peter

1 | AnzahlKafee1 | 2

1 | Netto | 5,00

1 | Brutto | 5,20

2 | Datum | 01.02.2021

2 | Kundenname | Claus

2 | AnzahlKaffee2 | 1

2 | Netto | 3.50

2 | Brutto | 5.20

2)Сделать классы, сериализовать и запихать объекты в БД. Не знаю как в других языках сериализуется, допустим в PHP одним оператором, допустим:

class Tabelle {

public $Datum;

public $Kundenname;

public $AnzahlKaffe1;

public $AnzahlKaffe2;

public $AnzahlKaffe3;

public $Netto;

public $Brutto;

public function __consctructor()

{

....

}

}

Дальше создаёте объект

$record1 = new Tabelle();

$record1.Datum = '01.02.2021';

А дальше сериализуете и записываете в СУБД:

см. https://www.php.net/manual/ru/function.serialize.php

$ser_object = serialize($record1);

В C# тоже есть https://docs.microsoft.com/ru-ru/dotnet/api/system.runtime...

B. Для NoSQL вообще проблемы нет, в MongoDB хранятся в формате типа JSON, только BSON. Хотя есть агрегация см. https://docs.mongodb.com/manual/aggregation/, я бы в Insert см. https://docs.mongodb.com/manual/reference/method/db.collec... всё сразу что надо запихал бы. Пишите так:

use DatabaseTabelle1

db.tabelle1.insert({"LaufendeNummer":"1", "Datum":"01.02.2021", "Kundenname":"Peter", "AnzahlKaffe1":"2", "Netto":"5.00", "Brutto":"5.20"})

db.tabelle1.insert({"LaufendeNummer":"2", "Datum":"01.02.2021", "Kundenname":"Claus", "AnzahlKaffe2":"2", "Netto":"3.50", "Brutto":"3.70"})

C. Можно сделать всё это ввиде объектов и спомощью LINQ.

P.S.:Но вообще есть ещё вариант, но о нём я скажу вечером. В кратце нужно создать таблицу AnzahlKaffee, в которой будут поля: LaufendeNummer - вторичный ключ, Kategorie - (1, 2 или 3), и Anzahl - число..., получитсячто-то типа такого:

1|1|2

2|2|1

3|3|1

Ну тут напрашиваются несколько таблиц:

1) Customer (customer_id, name)
2) Article (article_id, name, price_netto, vat)

3) Order (order_id, datetime)

4) OrderDetails (order_id(FK), customer_id (FK), article_id(FK), quantity)

пожалуй этого хватит

Основная таблица:

LaufendeNummer|Datum|KundenName|Netto|Brutto

1|01.02.2021|Peter|5.00|5.20

2|01.02.2021|Claus|3.50|3.70

3|01.02.2021|Wolfgang|2.50|2.70

Вторая таблица:

LaufendeNummer|Kategorie|Anzahl

1|1|2

2|2|1

3|3|1

Но лучше ещё так:

Основная таблица:

LaufendeNummer|Datum|KundenID|Netto|Brutto

2|01.02.2021|1|5.00|5.20

5|05.02.2021|1|7.00|7.40

Kunde:

KundenID|Name

1|Claus

3) Order (order_id, datetime)

4) OrderDetails (order_id(FK), customer_id (FK),

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

Юниор это работник с отсутствием опытa полностью закончивший обучение.

-----

Это в тебе говорит остаток (пост)советского обучения.

Ибо по официальной статистике МинОбразования США 18% выпускников школ элементарно - читать, писать и считать - неграмотны.

Скорее наоборот

-----

Что будет на рабочем месте - пусть будет на рабочем месте - там много что будет не так.

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

Помимо этого еще надо четко понимать какие цели ставятся перед ПУЧ.

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

В данном случае - должен осознать и явить понимание того что такое "нормальная форма" и уметь обосновать применение 3-й, а не 5-й.

Будут ли ошибки, будет ли рабочий код - не суть важно.

Важно - чтобы осознал формы и был готов к следующему шагу - осознанию возможностей и ограничений связанных с конкретной формой.

сказать чем, скажем 4NF отличается от 3-й?

-----

Нее, не вспомню...

Насчет - применить - вероятно - применю, но теорию - нее, не вспомню.

Ужос. Делать программу на основе таблицы.

-----

А куда ты денешься?

Есть какой-нибудь комплекс - базы и куча софта. Большой - у меня было 2 ГБ спагетти-сорцов.

Ты либо пишешь на тех базаx что есть, либо переписываешь все 2 ГБ спагетти.

Ибо там совершено непонятно где именно вылезет небольшое изменение в базе.

А слабо сейчас, никуда не глядя, сказать чем, скажем 4NF отличается от 3-й

А я не юниор

Вообще то когда я действительно пришел первый раз на первую фирму, я как раз этот самый 4-й уровень и пытался впендюрить

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

У меня внезапный взгляд с другой стороны: я бы поинтересовался где у этого чела письменные согласия клиентов на обработку и хранение их персональных данных (имя) :) И всегда ли Claus это тот же самый Claus.

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

А куда ты денешься?

В реальности никуда. Но это же мечтательно - учебный проект

1) Customer (customer_id, name)
2) Article (article_id, name, price_netto, vat)3) Order (order_id, datetime)4) OrderDetails (order_id(FK), customer_id (FK), article_id(FK), quantity)

НП

Тут напрашивается 3 класса и зависимости между ними. и, о чудо, мы действительно имеем место для сохранения Customer'a, Article и Order'a. Последняя таблица техническая для зависимостей.

И заметь, MrSanders написал "заказ только с одним клиентом связан".

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

Но для ПУЧ должно быть четко определено какую часть какой теории данная практика должна закрепить и теория должна быть доступна до начала работы над ПУЧ.

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

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

продиктованную задачами

Задачи как бы и описаны данной таблицей. Больше у заказчика ничего нет.

Просто берешь по учебнику и выполняешь предписанные шаги

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

я бы поинтересовался где у этого чела письменные согласия клиентов на обработку и хранение их персональных данных (имя)

Не подходит под DS-GVO Оказывается даже для рекламы разрешено использовать "имя, фамилию, почтовый адрес, год рождения." без всякого согласия. Как раз получил рекламу на дом и занялся "расследованием".

И всегда ли Claus это тот же самый Claus

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

Сделать классы, сериализовать и запихать объекты в БД

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

Ну тут напрашиваются несколько таблиц

вопрос только в том как до этого дойти самому не имея достаточного опыта.

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

Задачи как бы и описаны данной таблицей. Больше у заказчика ничего нет.

Заказчика убить. Он принес программисту готовое неправильное решение не написав, что это такое? Нет, ну реально, сделайте непонятно что из хрен знает чего? И это учебная задача?

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

не работает, результат просто смешной получается.

У меня работало. Я действительно давно именно с таким заданием не сталкивался(ну просто это абсолютно устаревший стиль программирования), но когда то действительно в учебнике была учебная задача и пошаговый алгоритм позволял ее нормализовать

Заказчика убить.

Ну тогда даже и пулемётов не напасёшься. Как то мне еще не попадался заказчик который бы предоставил идеальное ТЗ.

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

Но на таких задачах нельзя ни учится ни учить

Ну покажите мне хоть кто то "правильную задачу" и как вы бы на ней учили?

пошаговый алгоритм позволял ее нормализовать

Алгоритм мона?

Может просто им (студентам) книги тупые дали? Я не знаю, мне показали только решение.

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

Достаточно и одной. Правильно 3 для обьектов и технические таблицы для связей, которые зависят от определенных связей. Эти связи и Программист и MrSanders вычисляли из исходной таблицы. Отсутствие поставленной задачи привело к разночтению и появлению бага. Была бы задача с описанием ситуации - было бы нагляднее

Пример. Программисты имеют 3 паузы , пьют в них кофе и в конце дня получают зарплату. 01.02.2021 Петер в первую паузу выпил 2 чашки, а потом не пил и получил зарплату нетто-брутто. Я понимаю, что в данном конкретном случае это атягивание совы на глобус, но без задания можно много нафантазировать и напрограммировать.

Как то мне еще не попадался заказчик который бы предоставил идеальное ТЗ.

Да причем здесь идеальный? Он у вас еще и немой и только одна рука, из которой на обрывке бумаги торчит таблица. Просто муму какое-то

Ну покажите мне хоть кто то "правильную задачу" и как вы бы на ней учили?

Имеется предприятие по продаже кофе. Оно продает несколько разных сортов кофе. Каждый сорт стоит нетто + накладные расходы(брутто). Имеются клиенты, которые покупают это кофе. Нужно наладить учет продаж и хранение информации в базе данных. imho

Алгоритм мона?

Пожалуй нет. 20 лет все таки прошло. Ничего из этой литературы я не сохранил.

Имеется предприятие по продаже кофе...

Ну так это всё из таблицы и видно

Поэтому в первую очередь классы сущностей, а потом база данных.

-----

В Ентити Фрамеворк реализованы два подхода - коде фирст и датабасе фирст.

Основной вопрос - кто больше взаимодействует с клиентом - базовик или прогер.

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

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

потому как непонятно - проверено

-----

Именно так.

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

Мало того - нельзя делать - непонятно, еще раз непонятно и снова непонятно - результат такого подхода вполне предсказуем - пошло нафиг это ИТ...

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

-----

Да нет никаких проблем - есть таблица и в нее надо писать/читать данные.

Какие есть - такие и писать и в том виде в каком даст клиент.

А то, что потом отчет будет построить сложно - это тебе сейчас понятно, а юниору - нефига не понятно - он та далеко не думает - у него огромная проблема - сформировать скл-инсерт для вставки в таблицу...

У нас тобой разные точки зрения на процесс обучения.

-----

Обучившиеся у меня успешно работают по специальности... сменив несколько поколений систем разработки.

вопрос только в том как до этого дойти самому не имея достаточного опыта.

-----

ответ - изучить соответствующую часть теории.

у него огромная проблема - сформировать скл-инсерт для вставки в таблицу.

а не нужны нам никакие скл-ы

Обучившиеся у меня успешно работают по специальности

ну и что тебе мешеает повторить енто здесь?

ответ - изучить соответствующую часть теории.

ну не нужна пока никакая теория

Первое, что сразу видно, откуда брать цену на сорта кофе? И сортов несколько.

Значит нам нужна еще таблица по сортам кофе с ценами.

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

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

Ну так это всё из таблицы и видно

-----

Из нее ничего не "видно".

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

При этом не сказано, что можно добавлять строки и нельзя добавлять колонки.

Что именно представлено - не определено, ожидается оценка на основании (отсутствующегo) практического опыта.

Чтобы понять что именно не так - возьми ту же таблицу, но на китайском (иероглифами, именно так ее видит нуб) и поясни что там к чему.

ну и что тебе мешеает повторить енто здесь?

-----

А зачем? В смысле - зачем это надо мне?

Основной вопрос - кто больше взаимодействует с клиентом - базовик или прогер.

Какова цель процесса?Допустим базовик вылез вперед. В результате получаем какие то таблицы. Начинаем лепить код, пытаясь всунуть между описанием процесса клиенты и той хренью, которую налепил базовик. И потом ищем костыли, как сделать вот так, но но этак.
Есть стандартные решения для многих бизнес-процесов. Стандартные - это значит и проверенные на практике на стабильность, масштабируемость и легкость в сопровождении. И это значит, что проггер с первого взгляда узнает и понимает имплементацию. И есть решения "я это зделал, но не завидую тем, кто будет после меня разбираться с этим". Так вот, загоняя программиста между клиентом и базовиком мы вынуждаем его выкручиваться, лепя на коленке костыли. Итог немного предсказуем. Имхо.

ему нужно построить "правильную" базу

Я запущу на автомате построение базы и за 10 сек. получу готовую "правильную" базу из персистентного слоя. По готовым классам. Базовик месяц будет лепить таблицы и потом я еще полгода буду пытаться организовать сохранение в эти таблицы. И получится хрень.

и молится на то что под них будет создана "правильная" база.

Теперь я понимаю, Мурр, откуда твои вопросы про чудо чудное, которое делает диво дивное и в природе не существует. Окропление святой водой заменяет юниттесты

QНу так это всё из таблицы и видно

что видно? Что у программиста зарплата 7.00 нетто и 7.40 брутто? Я своих продактменеджеров за такие таблицы гоняю. Приказ, который может быть неправильно понят, будет неправильно понят.

не определит триггер, который будет синхронизировать текущую и стороннюю базы.

костыль детектед.

откуда брать цену на сорта кофе

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

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

Первое, что сразу видно, откуда брать цену на сорта кофе?

-----

Цена это куда?

Кофе это как?

Кому отослать - сорта?

Через что брать?

Все что "видно" - это только через твой личный опыт, через твою оценку содержания и, возможно, через какую-то дополнительную информацию от заказчика, которой ты не поделился.

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

В той стране откуда Я сбег после переворота была мода на написание учебников - советские им сильно не подошли.

Писали много, писали разное.

Вот в учебник математики попала задачка:

У Пети 4 яблока,

У Маши 2 груши.

РЕШИ.

Но там хоть понятна цель - уничтожить образование как таковое.

Цель была достигнута - выпускают инженеров с опциональным знанием арифметики.

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

Я всё понял

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

А зачем? В смысле - зачем это надо мне?

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

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

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

Поэтому в первую очередь классы сущностей, а потом база данных.

-----

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

???

и за 10 сек. получу

-----

Ну давай попробуем.

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

Ну или еще удобнее - вести лог (без информирования клиентa) записей просмотренных конкретной группой пользователей.

Если этого мало - Я найду еще кучу задач, каждая из которых выйдет за рамки простого хранения данных, подразумеваемого при использовании парадигмы коде фирст.

Не подходит под DS-GVO

Исчо как. Имя клиента это личная информация. Откуда его может узнать кофейня? Только если его сообщит клиент. (рекламщики могут валить на публичные источники вроде телефонной книги и "неперсонализированные" письма). Если кофейня собирается сохранять имя, она должна предупредить клиента и сохранить данное им согласие. А то будет больно.

костыль детектед.

-----

Нормальная практика аудита - любое изменение - вставка/замена/удаление - в базе логируется в другой базе. Программист об этом не уведомляется - ему об этом знать не нужно.

она мне всё рассказала, что там написано

-----

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

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

Как решать, да не знает.

-----

Ожидаемо.

Бо, требуется определить ряд понятий из области баз данных:

поле,

таблица,

запись,

первичный ключ,

ссылочный ключ,

реляция

и т.д. и т.п...

Потом нужно дать СКЛ и дать поошибаться на несоответствии типов, на нуллах, на отсутствующих ключах.

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

Но вот если раз рядом есть студент, то отчего бы не

-----

Ну почему бы не поделится?

Поделюсь, если буду видеть, что пойдет на пользу...

Но пока Я такого не наблюдаю.

Наблюдаю - потребителя, который говорит - Дай!

А - Дай - уехал в Китай и сказал - никому не давай.

К тому же моя помощь может поломать какой-то учебный процесс - Я не в курсе чему и по какой методике обучают. Могу, конечно, определить дыры и постараться их заткнуть, но, возможно, просто забегу вперед и заткнув дыркi не дам набрать ожидаемого опыта.

Не так все просто в обучении.

Имя клиента это личная информация

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

не умеет читать задачу по-прогерски

ну так студент это по определению еще не умеет

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

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

дать ссылку - пусть почитают теорию

-----

Ну ты же сам сказал - не готовы, не могут.

Пришлось указать что нужно положить в базис чтобы были готовы и могли.

ну так студент это по определению еще не умеет

-----

Ну так учи.

Я в себе читателя года три убивал...

Я всё понял

В таблице указаны космонавты, которые должны

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

Не пойду я к вам продукт менеджером, даже не зови больше

требуется определить ряд понятий

А чего их определять, иди в академию и изучай туториалы

https://htmlacademy.ru/tutorial/php/databases

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

иди в академию и изучай туториалы

-----

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

-----

Пример того как нельзя туторить:

https://docs.microsoft.com/ru-ru/office/troubleshoot/acces...

И пример того как можно туторить:

https://habr.com/ru/post/254773/

Задача - прежняя - определить триггер,

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

Я найду еще кучу задач, каждая из которых выйдет за рамки простого хранения данных,

Без сомнения. Но все это исключения из правил и вовсе не материал для обучения юниоров. Каждое исключение это пакт с дьяволом. Потому что именно ты сожалел о тех, кто должен это все понять, когда тебя не будет. 😁

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

Отлично. Не моя головная боль . Я программист. Ну почти 😁

Я программист. Ну почти

-----

Хммм... техник-кодировщик - сойдет...

-----

Действительно - не твоя головная боль.

Я запущу на автомате построение базы и за 10 сек. получу готовую "правильную" базу из персистентного слоя.

-----

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

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

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

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

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

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

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

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

Судя по таблице заказ только с одним клиентом связан. 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-мя способами. Кофе имеет цену. И покупка имеет стоимость, которую она получает от кофе в момент покупки. Тогда при изменении стоимости кофе стоимость покупки не меняется. Или при изменении цены на кофе просто закладывать новый товар.

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

-----

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

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

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

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

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

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

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

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

Никак.

-----

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

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

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

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

и

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

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

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

-----

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

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

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

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

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

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

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

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

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

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

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

-----

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

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

-----

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

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

-----

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

Хочешь несколько - дополнительный ключ в таблицу и... снова пункт 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" как-то привычнее

Кому как

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

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

-----

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

В чем смысл

-----

Не знаю.

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

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

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

Я еще не видел

-----

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

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

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

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

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

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

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

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

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

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

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

-----

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

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

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

-----

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

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

-----

Блин...

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

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

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

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

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

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

-----

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

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

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

-----

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

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

Смотри, пример из жизни. нужно зайти в комнату, пропылесосить, помыть полы, уйти из комнаты. У тебя это выглядит так. Работник заходит в дом и его замечает триггер. Пока работник поднимается по лестнице, триггер лезет в окно , пылесосит и убегает опять через окно. Работник заходит, опа, уже пропылесошено, осталось помыть полы. И все, блжет, работает. До тех пор, пока что то не изменили. И ВДРУГ стало непропылесошено. Кто, где когда пылесосил никто не знает, чртов триггер лазил через окно и его теперь никто не найдет.

Любой дурак может повесить триггер в конкретной базе данных. Нужен доступ и мануал. Но еще раз, триггеры - это последнее средство для стандартных мероприятий. Это внутренние дела базы данных, можно организовать логгирование, но никогда CRUD - операции

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

Потому что лепка у тебя самодельная. Если база сделана не под энтити, то черта с два ты их туда нормально засунешь. А это значит костыли в коде. А это значит херня.

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

Ничего. Кроме того, что сначала ты неделю программируешь базу данных. А потом я неделю набиваю по базе руками классы. А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу. Неделя экономии.

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

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

Любой дурак может повесить триггер в конкретной базе данных. Нужен доступ и мануал. Но еще раз, триггеры - это последнее средство для стандартных мероприятий. Это внутренние дела базы данных, можно организовать логгирование, но никогда CRUD - операции

В общем случае - нет. БД может использоваться как "связь" межу приложениями. Хоть это и не очень хорошо. И тогда триггер это самое простое и адекватное средство.

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

Если база сделана не под энтити, то черта с два ты их туда нормально засунешь.

Хибернейтом - геморройно. Что скорее говорит о качестве хибернейта. Ручками - без проблем.

А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу. Неделя экономии.

Ага. А потом три недели пытаемся оптимизировать запрос, для которого я пишу sql, отрабатывающий за 3 секунды, а хибернейт щелкает 3 часа если не вываливается с OutOfMemory. Получается проще 2 недели на базу и "ручной" доступ к ней потратить.

Надо сказать что я года с 2010 пытаюсь где только можно избегать хибернейта. Ну не работает такое общее решение в сложных приложениях. Его конфигурация становится чуть ли не самой сложной частью, которая ещё и с каждым bugfix-ом норовит сломаться. И в конце-концов всё равно пишем в самых критичных местах не hql а sql запросы. Ну и нафига тогда всё городить?

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

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

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

Хибернейтом - геморройно. Что скорее говорит о качестве хибернейта. Ручками - без проблем.

Нет. Хайбернет это только стандарт де факто. Если можно без проблем стандартно, то нестандартно - это коствль. Ф топку

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

Это говорит о качестве модели. И о умении пользоваться персистентным слоем.

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

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

Я понимаю, что когда корабль тонет, нужно использовать то, что есть. И цеплятся за доски. Или если по другому НИКАК нельзя, то можно то, что нельзя. Но в нормальной стандартной проге нужно (имхо) использовать только стандартные решения. И неважно, что нестандартные быстрее, если скорость не критична. Легкость сопровождения важнее. Имхо

если скорость не критична

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

Помнится были и триггеры и stored procedure и materialized view.

Обращаем внимание на постскриптум

https://habr.com/ru/post/146717/

постскриптум в тему.

нужно зайти в комнату, пропылесосить, помыть полы, уйти из комнаты.

-----

нужно зайти в комнату, помыть полы, уйти из комнаты?

никто не знает

-----

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

Потому что лепка у тебя самодельная.

-----

Какая разница какая она у меня?

Ентити - стандарт для .Нет и там ДВА варианта.

Кроме того, что сначала ты неделю программируешь базу данных.

-----

Ээээ???

Вообще-то, это на уровне подготовительной группы детского садика.

Если мне удобно - а иногда мне удобнее конвертировать документацию в скрипты - делаю скрипты. Да - руками, да - долго. Но обычно все же быстрее чем даже построение УМЛ.

Если мне не удобны скрипты - пользую любой редактор с визуальным представлением - хоть ЭМ, хоть Деварт, хоть... Аксесс...

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

-----

Ну это твое дело - хочешь руками - делай руками.

А вообще-то встроенный генератор кода есть. И если код не устраивает - можно и шаблоны подредактировать - пока код будет соответствовать требованиям, а там довольно вариативно, Ентити - никаких проблем не будет.

А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу.

-----

Ну и как ты туда триггер запихиваешь?

Попробую так.

Задачка из топика.

База - полностью, т.е. в 5-ю форму, нормализованная.

Что ты будешь делать чтобы собрать исходную таблицу?

Будешь утверждать что не надо 5-ю форму?

Или попросишь несколько вьюшек слепить?

А инструмент для вьюшек у тебя есть?

А если вьюшек не хватит и процедура потребуется?

Упсс - опять уперлись в инструменt...

Знакомый в Уни, начал подкидывать задачки.

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

Алгоритм может быть таким:

-1- включить зелёный машинам, пешеходам красный

-2- если пешеход нажал кнопку, и машинам зелёный горел уже достаточно долго

- включить машинам желтый

- чуть подождать

- включить машинам красный

- чуть подождать

- включить пешеходам зелёный

- выдержать достаточно времени для хождения пешеходов

- включить пешеходам красный, а машинам желтый

- чуть подождать

- включить машинам зеленый

- перейти к -2-

........

R,Y,G - лампочки светофора машинам

R2,G2 - лампочки светофора пешеходам

Алгоритм может быть таким

-----

Не может.

В алгоритмах УПРАВЛЕНИЯ вообще не может быть никакой прописанной логики. Тем более логики, в которой принимаемое решение зависит от того какой кусок кода выполнялся на предыдущем шаге.

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

Только тогда это работает.

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

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

В алгоритмах УПРАВЛЕНИЯ вообще не может быть никакой прописанной логики. Тем более логики, в которой принимаемое решение зависит от того какой кусок кода выполнялся на предыдущем шаге. В таких алгоритмах выделяется то что называется "текущее состояние" и на его базе строится обычный цифровой автомат.

Кстати на картинке изображен именно цифровой автомат (State Maschine). Точнее два.

А лампочки, как общеизвестно, имеют свойство регулярно перегорать...

на картинке изображен именно цифровой автомат

-----

Увы, но нет...

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

Функция перехода должна изменить (атомарная операция) текущее состояние.

Код автомата должен никак не зависеть от того из какого и в какое состояние автомат переключается. Вообще никак.

Как следствие - код автомата никак не должен зависеть от конфигурации перекрестка и выбранного режима работы светофоров - автомат будет один и тот же.

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

не требует никак обрабатывать эту ситуацию

-----

В Риге тоже не обрабатывали - два поезда столкнулись и появилась куча трупов...

П.С. Что данное решение не для осваивающих иф-елсе-тхен - Я вполне понимаю.

В Риге тоже не обрабатывали - два поезда столкнулись и появилась куча трупов...

Что данное решение не для осваивающих иф-елсе-тхен - Я вполне понимаю.

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

Код автомата должен никак не зависеть от того из какого и в какое состояние автомат переключается.

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

конечно специальные языки ее упрощают

Для этого нужно знать эти специальные языки и упрощение тоже еще вопрос.

Но перед алгоритмом нужно хоть немного описать задачу.

Похоже у нас есть два светофора стоящих на пешеходном переходе: один для машин, другой для пешеходов. Имеется еще кнопка запроса перехода.

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

Для этого нужно знать эти специальные языки и упрощение тоже еще вопрос.

Этот что на картинке подобен стандартному SFC.

https://ftp.owen.ru/CoDeSys3/98_Books/plcopen_sfc_v10_ru.p...

Именно на таком и следует программировать, если задача является последовательностью (во времени) шагов.

На текстовом языке, а ля C# или стандартном ST (а также на графических стандартных FBD, LD) этот алгоритм будет выглядеть гораздо менее привлекательным.

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

Нужно еще определится с алгоритмом запроса пешехода на переход.

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

https://m.habr.com/ru/post/254885/

Если выходной сигнал цифрового автомата зависит лишь от текущего состояния, то такой автомат называется автоматом Мура

😁

подкидывать задачки.

Вот реальная задача управления светом в подвале школы (как то товарищ попросил запрограммировать с его слов)

- есть кнопка.

- начальное состояние - выключить свет (если включен).

- при нажатии кнопки включить свет.

- если кнопка нажата коротко, то свет сам потом выключается через некоторое время. (далее начальное состояние)

- если кнопка нажата больше секунды (но меньше 10ти), то свет сам не выключится, а выключится повторным нажатием кнопки. (далее начальное состояние)

- если кнопку нажать очень долго (более 10 секунд), то свет моргает один раз (т.е. тухнет на 1 секунду и опять включается) и устанавливается некий сигнал (зачем нужен не знаю).

- после этого короткие нажатия кнопки игнорируются, а при долгом нажатии (10секунд), свет моргает 5 раз и тухнет, а некий сигнал сбрасывается через некоторое время начиная с начала 5тикратного моргания. (далее начальное состояние).

...

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

Если он пришел, свет включается, некий сигнал выключается, а вышеприведённый алгоритм отключается не зависимо от текущего его шага.

Когда аварийный сигнал уйдёт, то алгоритм стартует с начального состояния.

всё это соблюдено в диаграмме выше.

----

Увы-увы, но нету там этого.

Например, у тебя там НЕТ возможности переключить все светофоры перекрестка в "Мигающий Желтый".

А когда ты это попытаешься добавить - у тебя появится довольно неприятное усложнение логики.

Если допустить, что светофор дается произвольный - например один трех лампочный, другой - пяти, все снова усложнится.

А усложнения недолжно быть - функция автомата не поменялась - автомат должен управлять включением/выключением ламп светофора. И только.

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

-----

Это на самом деле - просто.

С - состояние

У - управляющее воздействие

Тогда автомат А определяется как

С = А(С,У).

Если У - пустое - нет кнопок или удаленного управления - будет С = А(С) или С = А(С,нулл)

А автомат переключается в любом случае - даже в том, когда С(до) тождественно равно С(после)

ввиду упрощенной задачи), ибо нет

-----

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

Но в сколь-нибудь реальном управлении так работать не будет. Нее - воткнуть - можно, но будут проблемы.

Грубо говоря - в реальной системе ты должен взять текущее С (например состояние ламп включено/выключено/перегорела плюс "режим работы") и текущее У (например, кнопки, таймер, ошибки) рассчитать новое С. На каждом шаге т.е. изменении состояния ламп - все пересчитываешь из лампы+ и все У... Дрючить "кодом автомата" какую-то одну лампу/кнопку/таймер - нельзя.

Тогда - будет работать.

Т.е. активация очередного состояния является следствием предыдущего и условия перехода.

-----

Тут ты упускаешь что после смены состояния (переключения ламп) автомат должен находится в позиции "готовность к очередному изменению состояния" и что это всегда одна и та же позиция.