MartinSt

Warum konzentrierst Du dich nicht auf die eigentlichen FIAE Aufgaben, dh. Aufsetzen der DB und Datenmigration?

Wieder unter der Einschränkung dass in BaWü die Regeln abweichen: Ja, sollst du. Ja in 35 Stunden.

Das ist für mich auch so ein Satz, wo man alles und nichts draus lesen kann. Nichts=eset ist auf deinem PC drauf und scanst damit und guckst mal in die Logs Alles = du administrierst Dutzende oder Hunderte Clients oder Server bezüglich deren eset-Konfiguration

Hallo, BaWü weicht zwar wesentlich vom Rest der Bundesländer ab, aber vermutlich ist hier gefragt, welche Doku für die Anwender/Nutzer du im Rahmen des Projekts erstellen wirst. Gruß Martin

Was ist das Problem, wenn Office 365 die Lösung ist?

Warum keine Prepared Statements? was soll da rein? "knapp 3 Stunden" Was meldet das Errorlog vom Webserver, vom PHP bzw Mysql?

Das klingt wie eine Hausaufgabe im Linux Scripting Kurs

Was erwartest Du jetzt? Je IHK und Ausbildungsberuf einen Prozentsatz?

Was ist denn das Problem, wenn ein virt. Server mit Debian 9 die Lösung ist?

Neben den sprachlichen Hinweisen und der berechtigten Frage zu Kaufen-oder-Selbst entwickeln noch Folgendes: HeidiSQL ist ein Frontend für verschiedene DBs, aber selber keine DB. Woher weißt Du vorab schon, welches die geeignete Technologie ist?

Bitte mal präzisieren: Server, PCs, mobile Geräte ....??

@Jen_H Du solltest wenigsten darauf hinweisen, dass man als Entwickler die Fragen nur sinnvoll beantworten kann, wenn man selbst NICHT der Projektleiter ist.

Mal ganz blöd und fachfremd gefragt: Es gibt doch zur elektr. Patientenakte schon einen Riesenaufwand, kiloweise Specs bis hin zu dedizierter VPN-Hardware. Nach dem 36C3 Vortrag dazu ist ja die techn. Infrastruktur und Krypto dabei nicht ungeschickt gemacht. Warum nun eine eigene Lösung bauen?

Das kannst du nicht wissen. Lohnberechnung ist selbst für Steuerberater ein komplexes Thema mit ständigen Änderungen. Und wenn der Gesetzgeber sagt, dass ab 2021 das Durchschnittsalter der Haustiere für den Lohn relevant ist, dann musst Du dein Modell erweitern. Lohn sollte man denen überlassen, die es können. Zur DSGVO: Schon mit den wenigen Angaben wie bspw. auf der Lohnsteuerkarte bist du im Bereich der besonderen personenbezogenen Daten und darfst dann das ganz große Gerät auspacken. Das heißt, an deinen Webserver, die DB, die Connections zur DB, die User, Rechte, Passworte, Aktualität aller Komponenten werden maximale Anforderungen gestellt.

Woher weißt Du schon jetzt welche Berechtigungsgruppen es geben wird? Anhand deiner Berechtigungsgruppen darf niemand Benutzer ändern oder löschen? Warum brauchst du sowohl MySQL als auch MSSQL? Woher weißt Du schon jetzt dass es nicht PostgreSQL, Oracle oder $DB ist? Dir ist klar was sich aus den Mitarbeiterdaten hinsichtlich DSGVO & Co ergibt? Dein Zeitplan sieht keine Korrektur von Bugs vor, die sich beim Test ergeben? Warum nur per PHP und nicht auch per DB-Nutzer/rollen? Du hast vorher schon ein Objektmodell /Klassendiagramm der DB erstellt und brauchst dann 4h für die Erstellung per SQL, Willst du das create .... in Stein meißeln?

Und? hast du getan was die Meldung sagt?

Im Jailer verbindest du dich per JDBC auf die DB, also mit dem üblichen Connection String, mit Host, Port usw

Probier mal http://jailer.sourceforge.net/

Im Fall a) betrifft das mMn auch alle Daten, die irgendwo in den Firmen-Backups liegen.

Wenn die Lehre als Koch eine klassische Ausbildung war, dann reden wir hier insgesamt ja von einer Lücke von mindestens 3-4 Jahren. Eine solche zeitliche Lücke würde mir beim Lesen immer komisch vorkommen; also beser rein nehmen.

Wenn es möglich ist, also vor Abgabe des Antrags, würde ich an deiner Stelle das Projekt nochmal hinterfragen: Der Stundenumfang ist ziemlich knapp und bietet wenig Zeit, sich im Projekt in neue Software, neue Themen einzuarbeiten. Ich würde für meine Azubis immer ein Thema favorisieren, was sie bereits kennen, wo sie sattelfest sind und wo sie sich wohlfühlen.

Im 2. Jahr solltest Du ja grob wissen, was DBs so tun und was man mit SQL macht. Als grobe Idee: Nimm ein Gerät das laufend relativ unstrukturierte Daten produziert, zum Beispiel Logfiles vom Server, Ereignisanzeige vom PC o.ä. Wirf die als JSON, XML in eine geeignete DB (PostgreSQL, MariaDB) Werte das Ganze mit den entsprechenden JSON-Möglichkeiten der DBs aus. Wenn du das Gerät, das Daten produziert nicht hast, baue dir ein Script, Cronjob o.ä. der permanent Daten produziert. Beispielhaft hier JSON-Daten in SQL-DBs

Bitte mal konkreter: Welche Schulausbildung, Berufsausbildung? Welche Klassenstufe, Ausbild.jahr? Welches Fach? Welcher Zeitumfang und Tiefgang?

Nein, denn du verwaltest Kunden- und Tourendaten, aber im Proj.ablauf steht nichts, dass du ein ER-Modell entwirfst oder eine DB erstellst du verwaltest Kunden- und Tourendaten, damit kommt wieder die Frage der personenbez. Daten die Lösungstechnik ist mit Sharepoint, PowerApps & Co fest vorgegeben du hast ein Problem und sollst es ergebnisoffen analysieren, erst dann ergibt sich die passende Technologie was ist das Problem, wenn ein elektr. Essensplan die Lösung ist du beachtest keinerlei Wirtschaftlichkeit, Make-or-Buy

Mal ein paar spontane provokante Fragen dazu: Wie verwirklichst du damit die GoBD-Anforderungen? Wie kannst du in 5 Jahren noch eine Originalrechnung reproduzieren? Du hast damit personenbezogene Daten? Wie erfüllst du die DSGVO-Anforderungen? Wie stellst du sicher, dass nicht jemand die Daten einer Rechnung nachträglich ändert? Es gibt ein Leben vor und nach der Rechnung; die Rechnungsdaten entstehen typischerweise aus erbrachten Lieferungen und Leistungen. Nach der Rechnung spielen doch die Zahlungsüberwachung, Mahnwesen, Umsatzauswertungen etc eine Rolle.