Select: Artikelnummer die nicht verwendet wurden

MysterioJN

SQL-Guru
Beiträge
158
EDIT: Vergesst es, nicht möglich....




Hallo zusammen,

Kurze Erläuterung:
Unsere Artikelnummern sind IMMER 4-stellig. ggf. mit links vorangestellten '0'en.

In der 'Nummernliste' habe ich die Spalten: rowid und Artikelnummer, die es bereits gibt.
Beispiel:
1 / 0004
2 / 0007
....

Ich brauch nun einen Select für ein Dropdown-Listenfeld, das mir alle Artikelnummer zwischen '0001' und '9999' anzeigt, die nicht in der 'Nummernliste' verwendet wurden.
Es müsste also u.a. gemäß obigem Beispiel die 0005 und die 0006 angezeigt werden.

Geht so etwas?


Hintergrund: Der Zuständige Mensch soll sich nicht durch die "Nummernliste" mit 9999 Artikeln wühlen müssen, sondern lediglich aus noch freien Nummern per Dropdown und persönlicher Gewichtung auswählen und entsprechend vergeben dürfen.


Kann man verstehen was ich benötige?

Herzliche Grüße
Marco


Edit: Theoretisch würde ich es mit einem Selfjoin: "... where nummerliste1.artikelnummer <> nummerliste2.artikelnummer" probieren, da aber die ganzen "freien" Artikelnummern NICHT in der Nummernliste vorhanden sind, klappt das natürlich nicht so.


Edit2: Bin mir sicher, das es gar nicht möglich ist, da die Artikelnummer ein String ist.
 
Zuletzt bearbeitet:
Werbung:
Möglich ist das, allerdings etwas knifflig. Gibt es eine Tabelle in der alle freien Artikelnummern irgendwie erkennbar sind? Wenn nicht, musst du eine Liste erzeugen. Das geht on the fly wenn man z.B. rekursiv hoch zählt.
 
Beispiel:
Code:
WITH t(artikelnr) AS (
   SELECT   1
   UNION ALL
   SELECT   t.artikelnr + 1
   FROM   t
   WHERE   t.artikelnr + 1 <= 9999
   )
SELECT   right('0000' + cast(t.artikelnr AS VARCHAR(4)),4)
FROM   t
LEFT JOIN artikel a
ON       t.artikelnr = a.artikelnr
WHERE   a.artikelnr IS NULL
AND       t.artikelnr <= ( SELECT max(cast(artikelnr AS INT)) FROM artikel ) + 10
OPTION (MAXRECURSION 10000)
Probleme:
1) Deine Nummern werden mit Nullen aufgefüllt. Was, wenn deine Artikelnummer mehr als vier Stellen bekommt?
2) MAXRECURSION muss natürlich hoch gesetzt werden wenn die höchste Artikelnummer über 10000 liegt. Den Wert im Code kann man aber nicht selbst per Abfrage vorgeben, da muss man dann mit dynmaischem SQL ran.
3) Wo hört man auf freie Nummern anzuzeigen? Ich habe es hier im WHERE-Teil bei der höchsten + 10 weitere eingetragen.
4) Du musst rum konvertieren, VARCHAR(4) und INT können zu klein werden.
 
Ich brauch nun einen Select für ein Dropdown-Listenfeld, das mir alle Artikelnummer zwischen '0001' und '9999' anzeigt, die nicht in der 'Nummernliste' verwendet wurden.
Es müsste also u.a. gemäß obigem Beispiel die 0005 und die 0006 angezeigt werden.
[...]
Hintergrund: Der Zuständige Mensch soll sich nicht durch die "Nummernliste" mit 9999 Artikeln wühlen müssen, sondern lediglich aus noch freien Nummern per Dropdown und persönlicher Gewichtung auswählen und entsprechend vergeben dürfen.

Wieso sollte ein Mitarbeiter überhaupt eine Artikelnummer festlegen? Wieso generiest du diese nicht selbst?
Woher soll ein Mitarbeiter wissen, was die richtige Artikelnummer ist?
 
Uff jetzt habt ihr euch doch damit beschäftigt *verneig*

Eine andere Tabelle gibt es nicht, aber du hast recht. Das wäre eigentlich am einfachsten nach dem Motto OUTER Join oder?

Deine Idee guck ich mir morgen auf Arbeit an. Bin ja Fan von deinen Abfragen und freu mich immer dazuzulernen! Danke schonmal.

Bzgl. der Artikel: Es kann maximal nur 9999 Artikel geben. Alle anderen Datenbanken/KLR/Haushalt sind so abgestimmt. Wir sind im öffentlichen Dienst und stellen seit 64 Jahren Publikationen her. Aktuell sind wir auf ca 2800 verbrauchte Artikelnummern. Wir haben also noch ewig Zeit... oder bis SAP "einzieht" *augenroll*

Die Artikelnummervergabe liegt in der Hand der Geschäftsführung und gibt eine Art Rang/Wichtigkeit bzw. früher sprechende Artikelarten wieder. Zumindest bisher.

Zukünftig würde ich echt am liebsten sagen: gib ihm die nächste "freie" Nummer. Dann hört das Durcheinander auch auf.

Also schonmal vielen Dank! Ich gebe morgen Feedback.
 
Wenn es eine andere Sortierung geben soll (Rang, Wichtigkeit) dann mach das unabhängig einer Artikelnummer.
Wenn z.B. von 0-99 alles vergeben ist und es kommt ein "wichtigerer" Artikel dazu müssten die Artikelnummern neu sortiert werden und das will man nicht.
 
Also bei nur max 9999 Artikelnummern müsste mein Code seinen Dienst tun. Ich würde aber drei Dinge in Betracht ziehen:
1) Unabhängig von der Artikelnummer eine ID einführen, falls noch nicht vorhanden. So das sowohl in der DB als auch im Front-End theoretisch identische Artikelnummern möglich wären. Das System muss das dann natürlich im Shop darstellen können und Bestellungen und so anhand der ID, nicht der Artikelnummer abwickeln.
So kann ein sorgfältiger Admin Notfalls eine sprechende Artikelnummer anpassen und es wäre eigentlich nur bei Telefonaten relevant, nicht im Shop. Ich fände die Option für Ausnahmesituationen hilfreich, vor allem wenn man Wert auf logisch vergebene Artikelnummern legt kann mal was dazwischen kommen.
2) Mit dem oben gezeigten Code kannst du auch eine Hilfstabelle mit allen 9999 Einträgen bestücken, ist dann etwas einfacher und muss nicht jedes mal eine Rekursion starten, auch wenn die jetzt keinen Anspruch an die DB stellt. Dann kannst du dadrauf deinen OUTER JOIN machen.
3) Richtig gut fände ich statt einen Dropdown ein Textfeld mit Autovervollständigung das dann immer die Artikelnummern (auch die vergeben) davor und dahinter live anzeigt und ggf. um den Artikelnamen ergänzt. Dann kann man der Logik folgen und sieht gleich ob man in der richtigen "Nachbarschaft" ist. Theoretisch kann man dann auch bewusst die selbe Nummer auswählen, das müsste dann beim Speichern abgefangen oder mit einer Warnung versehen werden.
Das geht natürlich nicht in jedem Front-End.
 
Werbung:
@Dukel: Leider ist das wie gesagt historisch damals so gewachsen - nicht auf meinen Mist ;)
Aber das "Ranking" wird nun eh abgeschafft. Dank dir für die Vorschläge!

@ukulele: Das von dir klappt echt prima! Ich hab dennoch nun eine weitere Tabelle entworfen, mit 9999 Zeilen, auf die ich mich im Select beziehe.
Der "fehlende Part" in meinem Kopf war die Where-Bedingung mit "is null" xD

Bzgl 1: Es gibt insgesamt 6 Datenbanken. In jeder wurde mehr oder weniger sauber gepflegt in den Jahren, von unterschiedlichen Personen und ohne einheitliche ID.
Ich bin nun hingegangen und habe aus all den Datenbanken eine ganz neu normalisierte aufgebaut. Diese hat natürlich eindeutige IDs pro Artikel / Auflage / etc.
Damals (von 1995 bis 1999) hat man an solche "Relationen" nicht gedacht.

Ich habe tausende von unterschiedlichsten Daten in mühsamer zum Teil manueller Aufbereitung in die "neue" Datenbank aufgenommen, gemäß mir als Leihe bekannter heutiger Standards.
Darauf habe ich dann ein DNN-FrontEnd gesetzt, was prima klappt und zukünftig nahezu alle Bereiche in einem System abdeckt.
Das war eine meiner Hauptbeschäftigungen in den letzten zwei Jahren.
Ab 01.Juli bin ich meine Arbeit (die Aufgaben) dann leider los und muss im Demand einsteigen...

Bzgl 2: Jup ist gefühlt schneller, bzw. fühlt sich so besser an.

Bzgl 3: Das ist eine geniale Idee. Hmmm. Das hätte aber nur funktioniert, wenn alles komplett neue Bestellnummern bekommen hätte und man nicht vor Jahren die eigentliche "sprechende" Systematik mal angewendet und man nicht angewendet hätte. Es ist daher einfach ein Chaos entstanden, weshalb ich diese sprechenden Eigenschaften wie z.B. Träger des Mediums (CD, DVD, Print, etc.) natürlich nicht mehr in der BstNr "festmache", sondern wie zahlreiche andere Informationen als weitere Spalten im Artikelstamm.

Ich bin euch sehr sehr dankbar und bin auch ein wenig traurig. Es lernt sich immer noch am Besten mit wirklichen Alltags-"Problemen". Und ob ich in Zukunft noch hier weitere lernen darf, ohne wirklich Praxisfälle zu haben, bin ich mir da nicht so sicher.

Aber sei es drum: Meinen ganz herzlichsten Dank !!!
 
Zurück
Oben