Задачи для начинающих
А мне не пофиг,
-----
Хи-хи... а мне пофиг что тебе не пофиг.
Бо, по факту, таблица - задана.
Какая ни есть - она уже определена.
какой смысл, делать то, что нужно выбросить сразу в помойку.
-----
Никакого.
Потому нефиг переделывать то, что после переделки пойдет в помойку.
Исключение - практическая учебная задача (ПУЧ).
Но для ПУЧ должно быть четко определено какую часть какой теории данная практика должна закрепить и теория должна быть доступна до начала работы над ПУЧ.
Ну так напиши как надо.
-----
Это - долго... и не нужно.
Достаточно указать какую часть теории надо изучить и использовать или дать ссылки на теорию.
показал экзель и сказал - хочу базу
-----
Ну и?
Вот - КАК ЕСТЬ - так и вколачиваешь в сервер.
Потому как пришелец не сказал, а ты - не добавил, в какой нормальной форме он это хочет...
а юниор, в принципе, не имеет понятия об том что есть какие-то нормальные формы и пока не ознакомится с теорией ему фиолетово на нормализации которые ты от него ожидаешь... просто не поймет об чем речь...
А уж делать на этой основе программу, совсем ужос.
Ужос. Делать программу на основе таблицы. Программа- это средство для обработки информации. И использует базу данных для хранения этой самой информации. Каждая программа имеет архитектуру, продиктованную задачами и организация хранения должна соответствовать этпй архитектуре. Вы же получили склад и думаете, какой бизнес можно замутить с этим складом. Начинать нужно с проги. И под нее органозовывать БД. Имхо
Что касается нормализации баз данных это алгоритм. Просто берешь по учебнику и выполняешь предписанные шаги.
а юниор, в принципе, не имеет понятия об том что есть какие-то нормальные формы и пока не ознакомится с теорией ему
Юниор теорию знать ДОЛЖЕН. Иначе это не юниор, а ученик. Юниор это работник с отсутствием опыт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
Основная таблица:
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
Юниор это работник с отсутствием опытa полностью закончивший обучение.
-----
Это в тебе говорит остаток (пост)советского обучения.
Ибо по официальной статистике МинОбразования США 18% выпускников школ элементарно - читать, писать и считать - неграмотны.
Скорее наоборот
-----
Что будет на рабочем месте - пусть будет на рабочем месте - там много что будет не так.
В топике же говорится про задачи для начинающих. Т.е. для тех, у кого если и есть какая-то теория в голове то с практикой она никак не связана. Потому нужно не просто давать понятную себе постановку задачи, а сопровождать оную ссылкой на теорию.
Помимо этого еще надо четко понимать какие цели ставятся перед ПУЧ.
И эти цели - не нормализация никому не нужной таблицы, а то чего требуется добиться от обучаемого.
В данном случае - должен осознать и явить понимание того что такое "нормальная форма" и уметь обосновать применение 3-й, а не 5-й.
Будут ли ошибки, будет ли рабочий код - не суть важно.
Важно - чтобы осознал формы и был готов к следующему шагу - осознанию возможностей и ограничений связанных с конкретной формой.
Ужос. Делать программу на основе таблицы.
-----
А куда ты денешься?
Есть какой-нибудь комплекс - базы и куча софта. Большой - у меня было 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
хорошо, что обратили внимание. Это был один из подводных камней о которых хорошо бы споткнутся.