Вопрос по DB

[Батька]

Не могу найти подходящее название для attribute of an entity.

Тема - установка солнечных батарей на крышу дома.
Помимо прочего хозяева дома хотят определить cost effectiveness установки солнечных батарей на крыше дома и хранить эти данные в базе.
В базе уже хранится среднее количество солнечного света, падающего на крышу в течение дня (hours per day).
Также хранится площадь крыши в квадратных метрах.
Крыш много.
Разумеется, глядя только на эти две цифры, неудобно навзлет определять, которая из крыш больше подходит для установки батарей.
Поэтому вводим еще один attribute крыши, некоторый коэффициент, который находим путем умножения площади крыши на количество солнечных часов в день.
Чем больше коэффициент, тем больше метро-часов получает крыша за один день.
Логично?

Вопрос: как назвать этот коэффициент "метро-часов"?

Или, может быть, кто-то видит более удачное решение, чем мой коэффициент.

[Strannik]

такие вещи в базе не хранят обычно

SELECT SunHours, RoofArea, SunHours*RoofArea as RoofHours FROM table WHERE ... и так далее

[Батька]

такие вещи в базе не хранят обычно

SELECT SunHours, RoofArea, SunHours*RoofArea as RoofHours FROM table WHERE ... и так далее

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

[Батька]

Название мне подскажите, пожалуйста.
Дело еще не дошло до таблиц, все пока что на уровне entity relationship diagram, поэтому для RoofHours нужно meaningful название.

[Strannik]

такие вещи в базе не хранят обычно

SELECT SunHours, RoofArea, SunHours*RoofArea as RoofHours FROM table WHERE ... и так далее

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

Спросите у вашего координатора про database normalisation.

И я конечно не знаю спецификаций, но следуя common sense число вполне может меняться при изменении одного из параметров.

А имя я вам уже сказал RoofHours или RoofSunHours

[Батька]

Спросите у вашего координатора про database normalisation.

И я конечно не знаю спецификаций, но следуя common sense число вполне может меняться при изменении одного из параметров.

А имя я вам уже сказал RoofHours или RoofSunHours

Про normalisation краем уха слыхали.
А число меняться не может. Оно вычисляется раз и навсегда, чтоб определить cost effectiveness солнечного предприятия.
Количество солнечных часов берется среднее за период.
Самое интересное, что модель не требует хранить промежуточные данные для подсчета среднего количества.
Я вообще не понимаю, зачем хранить эти данные, для истории разве что.
Но такие условия задачи.
Приучают нас, наверное, к мысли: клиент сказал - пацан сделал.

[Andrej]

Спросите у вашего координатора про database normalisation.

И я конечно не знаю спецификаций, но следуя common sense число вполне может меняться при изменении одного из параметров.

А имя я вам уже сказал RoofHours или RoofSunHours

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

То Батька:
Если вы учитесь, то учитесь сразу правильному дизайну, что б потом не переучиваться