AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

SQL Vereinfachen

Ein Thema von Medium · begonnen am 16. Feb 2012 · letzter Beitrag vom 17. Feb 2012
Antwort Antwort
Medium

Registriert seit: 23. Jan 2008
3.688 Beiträge
 
Delphi 2007 Enterprise
 
#1

AW: SQL Vereinfachen

  Alt 17. Feb 2012, 12:02
@haentschman: Die DB ist nicht perfekt, aber durchaus gut strukturiert. Das ist auch das erste Mal, dass ich in dem Projekt so etwas großes an SQL brauchte. Ehemals wurde diese Funktionalität in einer grausigen Delphi-Routine gemacht, die in 3 Queries zigfach rumgeschleift ist. Das wollte ich eigentlich nur aufhübschen
Das knifflige hier ist wohl vor allem, dass in den Rezepten Rohstoffe stehen, und nicht direkt die Quellbehälter. Die sind zwar meistens 1:1 zugeordnet, aber ich musste Rohstoffe und Behälter jetzt entkoppeln, da jetzt teilweise wechselnde Rohstoffe in den gleichen Quellen gelagert werden.

Die Struktur der Tabellen ist in #1 angedeutet.

@Jumpy: In der Tat! Ui, danke für den Hinweis.
Die unterschiedlichen Kombis sind möglich, jedoch brauche ich diese hier nicht konkret. Ich muss nur wissen "es geht". Ich guck mal, wo das Distinct hin müsste, das sollte aber so gehen. Danke!
\\Edit: Ein DISTINCT im 2. Subselect (SELECT DISTINCT b1.rohstoff, b2.behnr, b2.name FROM qundz qz) tut das richtige. Es ist damit sogar richtig behandelt, wenn ich in einem Rezept mehr als eine Position mit dem selben Rohstoff habe! Ich glaube, das ist schon ganz okay so.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)

Geändert von Medium (17. Feb 2012 um 12:10 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#2

AW: SQL Vereinfachen

  Alt 17. Feb 2012, 13:04
@haentschman: Die DB ist nicht perfekt, aber durchaus gut strukturiert. Das ist auch das erste Mal, dass ich in dem Projekt so etwas großes an SQL brauchte. Ehemals wurde diese Funktionalität in einer grausigen Delphi-Routine gemacht, die in 3 Queries zigfach rumgeschleift ist. Das wollte ich eigentlich nur aufhübschen
Bitte versuch es doch "richtig" zu machen. Ich habe den Eindruck, daß in Deiner DB noch die Zettelkastenmentalität vorherrscht. Was man sehen kann ist auch so.
Wenn dann die Darstellung verändert wird, sind auf einmal alle so offensichtlichen Informationen weg.
Ist nicht gegen Dich gerichtet, nur als gut gemeinter Rat zu verstehen.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.688 Beiträge
 
Delphi 2007 Enterprise
 
#3

AW: SQL Vereinfachen

  Alt 17. Feb 2012, 14:46
Ich würde es durchaus "richtig" machen, jedoch bin ich nicht sicher an welcher Stelle da angefasst werden sollte. Eventuell könnt ihr mir da einen Rat geben, wie sich die Struktur vereinfachen würde.

Bislang schaut es so aus:

Tabelle "beh" - Behälterdaten (beinhaltet alle Quell- und Zielbehälter, manche treten auch als beides auf)
- id
- behnr (eindeutig, nicht fortlaufend, vom Kunden vorgegeben)
- name (Klartext, der im Programm statt der Nummer verwendet wird)
- min (Produktmindestfüllstand, ab dem die Pumpe unter dem Behälter gefährdet wäre trocken zu laufen, in Liter)
- max (Produktmaximalfüllstand, darüber sprechen die Überfüllsichrungen an. Sicherer Maximalstand, in Liter)
- ist (Aktueller Produktfüllstand in Liter)
- ziel (aktuell angeschaltetes Ziel, versorgt von der zugehörigen SPS, es kann immer nur genau ein aktuelles Ziel geben.)
- rohstoff (Rohstoffnummer des im Behälter befindlichen Materials, eingepflegt vom Anlagenbediener nach Anlieferung und Befüllung. Fremdschlüssel auf rohstoffe.rnummer)
- kenn1
- kenn2 (ein und der selbe Rohstoff kann in unterschiedlichen Qualitäten geliefert werden, die sich auch nicht in je eigene Rohstoffe untergliedern lassen weil Abweichungen zu divers. Hat nachher Einfluss auf die Dosiermengen. Die betroffenen Quellbehälter sind aber immer "Lieferrein", d.h. Qualitäten mischen sich niemals.)

Tabelle "Rohstoffe"
- id
- rnummer (eindeutig, nicht fortlaufend, vom Kunden vorgegeben)
- rname (Klartext zum Rohstoff)
- comment (Freies Kommentarfeld)

Tabelle "qundz"
- id
- quelle (Fremdschlüssel auf beh.behnr)
- ziel (Fremdschlüssel auf beh.behnr)

Tabelle "rezepte"
- id
- reznr (Rezeptnummer eindeutig, vom Kunden vorgegeben, nicht fortlaufend)
- rezname (Klartext des Produktes)

Tabelle "rezpos" (Die einzelnen Rezeptpositionen)
- id
- reznr (Fremdschlüssel auf rezepte.reznr)
- posid (ID einer Position innerhalb eines Rezeptes. Fortlaufend, programmintern vergeben und verwaltet)
- typ (Positionstyp. Kann sein "Dosieren, Rührwerk ein, Rührwerk aus, Probenahme, Heizen, Kühlen, etc. pp)
- soll1 (Sollwert 1, Interpretation über "typ")
- soll2 (Sollwert 2, Interpretation über "typ")
- rohstoff (nur für Dosierpositionen relevant, Fremdschlüssel zu rohstoffe.rnummer)
- formula (Mengenberechnungsformel für Dosierpositionen, deren Menge nicht absolut ist, sondern sich entweder auf zuvor dosierte Positionen oder Bedienereingaben beim Einwiegen oder Kennzahlen aus der Behältertabelle für den jeweiligen Quelltank bezieht)
- refIDA (Fremdschlüssel auf rezpos.id, Referenzdosierposition für in Formel verwendete Variable A)
- refIDB (Fremdschlüssel auf rezpos.id, Referenzdosierposition für in Formel verwendete Variable B)

Die "id" Felder werden für das Programm zwingend benötigt, dass die Kommunikation zwischen SPS und Datenbank herstellt. Nicht alle Tabellen sind an dieser beteiligt, aber ich fand es nur konsequent dieses Feld so dann überall zu führen. (Und im Nachhinein ist man meiner Erfahrung nach hier und da ja doch glücklich, einen einheitlichen Mechanismus zur eindeutigen Satzidentifikation zu haben.)

Die beiden Rezepttabellen sind Stammrezeptdaten. Diese Tabellen gibt es nochmals mit Suffix "_proz" für gestartete Rezepturen, die gerade in der Anlage bearbeitet werden. Dort kommt noch in "rezepte_proz" ein Feld "ziel" hinzu (Fremdschlüssel auf beh.behnummer, Mischbehälter für Rezept - das ist der, der vom Bediener über die Combobox auswählen können soll, um die es hier die ganze Zeit geht), und ein "status", der aus der SPS versorgt wird. Die Rezeptpositionen werden ebenfalls um einen Status, sowie "ist1" und "ist2" ergänzt, die ebenfalls aus der SPS kommen. In der "rezpos_proz" können beliebige Positionen "Nachdosieren" nachträglich an ein Rezept angehängt werden, sie unterscheiden sich also potenziell nach Fertigstellung auch strukturell vom Stammrezept.
Es gibt noch ein drittes ähnlich strukturiertes Tabellenpaar mit ein paar mehr Randdaten vom Bediener, in die fertig hergestellte Rezepturen zur späteren Statistik archiviert werden.

An der "rezpos" kann ich nicht viel drehen, da sie strukturell stark an einen Kommunikationsdatenbaustein in der SPS gekoppelt ist. Änderungen dort sind deutlich zu aufwendig, dann lieber 1-2 "interessante" SQL-Statements im Programm Was sollte ich hier idealerweise umstellen, um flexibler zu werden, bzw. mit einfacheren Statements auszukommen? Ernste Frage, keine rethorische - ich fühl mich nicht angegriffen, bräuchte aber konkretere Klappse auf den Hinterkopf als "machs halt besser", weil ich wohl zu sehr im Saft eingesickert bin gerade, als dass ich spontan benennen könnte was überhaupt besser ist =) (Die Rezeptbearbeitung ist ja nur ein kleiner Teil des Ganzen, und so Kunden sind ja immer ungeduldig ) Da ich aber gerade die Chance habe das Altsystem anzufassen, würde ich es schon ganz gerne gleich vernünftig machen.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)

Geändert von Medium (17. Feb 2012 um 14:58 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:22 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz