mal auf die Schnelle zu Deinen ersten beiden Punkten.
Du würdest nicht solche (riesigen) Joins bauen und das Ergebnis editieren.
Solche ein Select wie unter (1) würdest Du ggf in einem Report benötigen, vermutlich nicht mal da.
Wenn Du Adressen erfasst (Eingabe), hast Du ein
query für die Adresstabelle. Wenn es ein Artikel ist, dann ein
Query für die Artikel usw.
Verbindungen wie Du sie im Selectstatement oben später nutzt, stellst Du bei der Eingabe bspw. durch DBLookupcombobox her oder durch die Nutzung von Master Detail Properties in Datasets.
Damit würde ich jedenfalls anfangen. Eins nach dem anderen. Erfassung von Kunden, Kundenadressn, Artikeln usw., alles nach dem gleichen Muster.
Wenn das läuft und das Vorgehen / Implementierung klar ist, kannst Du komplexere Eingabemasken in Angriff nehmen, z.B. gemeinsame Erfassung von Kunde und Hauptanschrift. Usw. usf.
Wichtig ist erstmal, dass Du alles sauber rein und raus bekommst (und bei Bedarf reporten kannst> hier sind dann je nachdem größere Joins notwendig, mit einem guten Reportdesigner aber auch nicht so sehr)
Vergessen: Berechnung von Preisen etc. , Dein Ansatz ist ok, man kann hier und an anderen Stellen über die Nutzung von Views nachdenken. Das sind sozuagen benannte select Statement, mit denen man immer wieder kehrende Aufgaben (Darstellungen) sauber abbilden kann.