nicht angemeldet
TS
TS
Felix Riesterer
TS
TS
Rolf B
Rolf B
MudGuard
Hallo,
ich habe im Netz nach einer Funktion in php gesucht, die eindeutige IDs erzeugt, die nur aus Ziffern bestehen.
Wirklich brauchbares habe ich nicht gefunden.
Hintergrund: Ich möchte für Artikel eigene interne Artikelnummern vergeben. So könnte ich Vorgänge (z.b. Angebote) mit Artikelnummer erstellen, die aber vom Kunden nicht gleich im Internet gesucht werden können, ob sie woanders vielleicht billiger sind. Oder vom Mitbewerber, oder, oder...
Am einfachsten wäre es ja, ich könnte die Artikel-ID aus mysql nehmen, weil die ohnehin eindeutig ist. Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dsann die neuen eintrage. Somit würde dann ein- und derselbe Artikel nicht nur einen neuen Preis, sondern auch eine neue interne Artikelnummer erhalten. Das gefällt mir nicht.
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann.
Vielleicht könnte ich einen hash aus LieferantenID und Artikelnummer machen? Aber der würde sicher ziemlich lang werden.
Hat jemand von Euch eine Idee?
Hank
HH = Hello Hank, ;-)
ich habe im Netz nach einer Funktion in php gesucht, die eindeutige IDs erzeugt, die nur aus Ziffern bestehen.
Wirklich brauchbares habe ich nicht gefunden.
PHP kennt die Funktion uniqid
Nach diesem Vorbild könntest Du auch eine eigene Nummer generieren.
Aber das ist mMn der falsche Ansatz. Eine Artikelnummer sollte durchaus auch Sinn haben. Z. B.:
KAB-NYM-0525-001-9
Wobei die Prüfziffer jetzt noch nicht stimmt, die ist frei erfunden.
Oder als EAN-8 oder EAN-13-Code o. ä. aufbauen. Das wirst Du später nicht bereuen.
Und wenn die Artikelnummern in der Datenbank stehen, sollte man zunächst nicht ohne Benutzeranmeldung herankommen. Ein Vergleich im Internet dürfte daher schwierig werden. Aber man sucht üblicherweise nach der Artikelbeschreibung. Und einige Deep-Links in den Shop bei den Suchmaschinen sind normalerweise auch erwünscht.
Die Benutzeranmeldung ist auch wichtig für die Führung von angefangenen oder gespeicherten Warenkörben.
Die Stichworte hierfür lauten Convenience und Usability oder auf Deutsch: je einfacher Du es deinen Shopbesuchern machst, das passende Produkt zu finden, desto lieber werden sie kaufen.
Der große Zoni-Shop hat das bis heute nicht fertig gebracht :-(
Glück Auf
Tom vom Berg
Hallo,
Und wenn die Artikelnummern in der Datenbank stehen, sollte man zunächst nicht ohne Benutzeranmeldung herankommen. Ein Vergleich im Internet dürfte daher schwierig werden.
Die Benutzeranmeldung ist auch wichtig für die Führung von angefangenen oder gespeicherten Warenkörben.
Es geht um ein Angebot, auf dem ich Artikelnummern ausweisen möchte.
Hintergrund: Ich möchte für Artikel eigene interne Artikelnummern vergeben. So könnte ich Vorgänge (z.b. Angebote) mit Artikelnummer erstellen, die aber vom Kunden nicht gleich im Internet gesucht werden können, ob sie woanders vielleicht billiger sind. Oder vom Mitbewerber, oder, oder...
Am einfachsten wäre es ja, ich könnte die Artikel-ID aus mysql nehmen, weil die ohnehin eindeutig ist. Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dsann die neuen eintrage. Somit würde dann ein- und derselbe Artikel nicht nur einen neuen Preis, sondern auch eine neue interne Artikelnummer erhalten. Das gefällt mir nicht.
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann. Vielleicht könnte ich einen hash aus LieferantenID und Artikelnummer machen? Aber der würde sicher ziemlich lang werden.
Hello,
Am einfachsten wäre es ja, ich könnte die Artikel-ID aus mysql nehmen, weil die ohnehin eindeutig ist. Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dsann die neuen eintrage. Somit würde dann ein- und derselbe Artikel nicht nur einen neuen Preis, sondern auch eine neue interne Artikelnummer erhalten. Das gefällt mir nicht.
Bring bitte nicht Stammdaten und Bewegungsdaten durcheinander.
Der aktuelle Preis hat im Stammdatensatz des Artikels nichts zu suchen. Der gehört in eine separate Tabelle, die nach Lieferant, Preisdatum, usw. an den Artikelstammsatz gekoppelt wird. So erhälst Du auch eine Historiemöglichkeit.
Und die Lagermenge ist dann eine weitere Tabelle.
Glück Auf
Tom vom Berg
Hi,
Bring bitte nicht Stammdaten und Bewegungsdaten durcheinander.
Der aktuelle Preis hat im Stammdatensatz des Artikels nichts zu suchen. Der gehört in eine separate Tabelle, die nach Lieferant, Preisdatum, usw. an den Artikelstammsatz gekoppelt wird. So erhälst Du auch eine Historiemöglichkeit.Und die Lagermenge ist dann eine weitere Tabelle.
Ja, wenn ich das so organisiert hätte, dann gäbs mein Problem ja nicht.
Ich habe es aber anders organisiert und werde nicht umorganisieren, auch wenn ich Dir grundsätzlich recht gebe, dass ich das zuvor hätte normalisieren sollen.
Hank
Lieber Hank,
Ja, wenn ich das so organisiert hätte, dann gäbs mein Problem ja nicht.
Ich habe es aber anders organisiert und werde nicht umorganisieren, auch wenn ich Dir grundsätzlich recht gebe, dass ich das zuvor hätte normalisieren sollen.
Klarer Kandidat für 2504
Liebe Grüße
Felix Riesterer
Lieber Hank,
Ja, wenn ich das so organisiert hätte, dann gäbs mein Problem ja nicht.
Ich habe es aber anders organisiert und werde nicht umorganisieren, auch wenn ich Dir grundsätzlich recht gebe, dass ich das zuvor hätte normalisieren sollen.
Klarer Kandidat für 2504
Jepp. Bekanntermaßen nützt es herzlich wenig, einer Person - die sich fest zum Scheitern entschlossen hat - von einer Vorgehensweise abbringen zu wollen, welche derart zwingend und also vorhersehbar zum Scheitern führt.
„Hank“ will wohl ein Buch darüber schreiben, wie man es warum nicht macht. Und braucht dazu eigene Negativ-Er/[gl]/ebnisse statt Be/[kl]/ehrungen.
Ey Leute, Fragesteller dürfen nur gemobbt werden, wenn sie Vereinsmitglieder sind!
Ihr kennt die Sachzwänge und Kostenlimits nicht, denen Hank unterliegt. Ein Neubau eines Systems ist vor allem eines: teuer. Das muss man erstmal genehmigt kriegen.
Wir können ein Redesign anraten, aber wenn er nicht will, kann oder darf, ist das seine Sache.
Rolf
Im Kern mal hast Du natürlich Recht. Ich hätte, statt mich in meiner Verärgerung gehen zu lassen, zurückhaltender formulieren sollen. Vor allem, weil ich selbst genau diese Zurückhaltung anmahne.
Ihr kennt die Sachzwänge und Kostenlimits nicht, denen Hank unterliegt.
Meinst Du? Meinst Du.
Denn Aussagen, wie z.B.
Hintergrund: Ich möchte für Artikel eigene interne Artikelnummern vergeben.
passen (wegen der vielen „ich“) nicht zu:
Ein Neubau eines Systems ist vor allem eines: teuer. Das muss man erstmal genehmigt kriegen.
Ich denke auch, dass von einem „Neubau“ noch keine Rede sein kann, denn dazu müsste etwas halbwegs funktionsfähiges abgerissen werden. Vielmehr vermute ich etwas wie eine aktive Probierphase, in der „teilfunktionsfähige Abschnitte des Gesamtvorhabens“ angetestet werden.
Daraus könnte Hank sich als funktionsfähig erweisendes in die eigentliche Realisierung übernehmen.
Wir können ein Redesign anraten,
Ja. Und meine einzige Absicht ist es, dessen Unumgänglichkeit klarzumachen. Denn jede Minute, die mit den bisherigen Vorstellungen weiter gearbeitet wird, sind mehr oder weniger „für die Katz“. Gerade die Verweigerung einer Umstellung in dieser offensichtlich frühen Phase des Projektes ist deshalb sachlich nicht nachvollziehbar, weshalb ich das Schlagwort gewählt habe.
Wenn ich mir „was Geniales“ einfallen lasse und dessen Realisierung angehe, dann bin ich mir von Anfang an sicher, dass ich beachtliche Mengen meines eigenen Murkses nach dem Motto „Mist! Wieder was gelernt.” mit der DEL-Taste verbessere.
in dieser offensichtlich frühen Phase des Projektes
in dieser offensichtlich frühen Phase des Projektes
Mag sein. Aber Dein Projekt ist ja gerade, am Shop manches zu ändern. Und dafür hast Du sicherlich viele gute Gründe.
in dieser offensichtlich frühen Phase des Projektes
Mag sein. Aber Dein Projekt ist ja gerade, am Shop manches zu ändern. Und dafür hast Du sicherlich viele gute Gründe.
2 x nein.
Es haben immer wieder mal Kunden sich darüber ausgelassen, wie sehr es nervt, wenn sie ein Angebot mit viel Mühe und Arbeit erstellt haben und ihr Kunde dann entweder jeden Preis im Netz googelt, um dann nachzuverhandeln oder schlimmer, mit dem Angebot gleich zum Wettbewerber rennen. Der hat dann nicht mehr die Arbeit, die richtigen Artikel über Stunden hinweg heraus suchen zu müssen, sondern kann einfach das Angebot meines Kunden nehmen und seine Preise etwas günsiger einsetzen. Was ja auch passt, denn er muss die Stunden des Angebots nicht mehr auf die Artikel umlegen.
Bisher vermeiden wir das, indem die Artikelnummern komplett ausblendbar sind.
Schöner wären aber eigene Artikelnummern.
Soll heißen, ich habe nicht viele gute Gründe, sondern es wäre ein schönes "nice 2 have".
wie sehr es nervt, wenn sie ein Angebot mit viel Mühe und Arbeit erstellt haben und ihr Kunde dann entweder jeden Preis im Netz googelt, um dann nachzuverhandeln oder schlimmer, mit dem Angebot gleich zum Wettbewerber rennen.
Das Problem hat jeder, der ein Produkt vertreibt, welches dessen Kunden auch von anderen Quellen beziehen kann.(¹)
Der hat dann nicht mehr die Arbeit, die richtigen Artikel über Stunden hinweg heraus suchen zu müssen, sondern kann einfach das Angebot meines Kunden nehmen und seine Preise etwas günsiger einsetzen.
Also, wenn es Dir rein darum geht, keine EAN zu verbreiten, dann hast Du ja schon Vorschläge für eine UID oder interne Shop-ID mit ausreichender Sicherheit/Unterscheidbarkeit bekommen.
Ich weiß ja jetzt nicht, was Deine Kunden für Waren anbieten. z.B. bei manchen Ersatzteilen ist es unumgänglich, die Teilenummer des ursprünglichen Herstellers mit aufzunehmen. („Ersetzt Teilenummer XYZ-0815“), weil damit eine Reihe von Zusicherungen verbunden sind - vor allem die, dass das Teil ohne Umbauten als Ersatzteil verwendbar ist und sodann auch funktioniert.
Es kann also sein, dass eine solche Angabe zwingend ist, weil die Kunden Deiner Kunden keine Kunden Deiner Kunden mehr sind, wenn diese - ihnen kaufentscheident wichtige - Angabe fehlt.
¹) Alleinstellungsmerkmale baut man in einem solchen Markt anders auf. So ist z.B. ein Lieferantenwechsel durchaus auch mit Aufwand - und Risiken - verbunden. Kunden, die gehen, weil es anderswo wenige % billiger ist, muss man auch mal ziehen lassen, weil man sonst den Service, die Qualität und die Liefertreue auf das Niveau der billigeren Anbieter runterziehen muss.
Hallo Raketenwilli,
warum auch immer Du dies hier im Abstand von 4 Minuten neu gepostet hast - ich hab die Version von 12:06 mal in den Orkus geschickt.
Rolf
Hallo Rolf!
ich hab die Version von 12:06 mal in den Orkus geschickt.
Erstmal: Danke!
warum auch immer Du dies hier im Abstand von 4 Minuten neu gepostet hast -
Ja. Das Forum reagiert manchmal merkwürdig, wenn man nach einigem Vor- und Zurück im Browser seine eigene Antwort bearbeiten will und trägt dann die beabsichtigte Bearbeitung als neue Antwort ein. Das passiert nicht nur mir.
@@Raketenwilli
Ja. Das Forum reagiert manchmal merkwürdig, wenn man nach einigem Vor- und Zurück im Browser seine eigene Antwort bearbeiten will und trägt dann die beabsichtigte Bearbeitung als neue Antwort ein. Das passiert nicht nur mir.
Die Buttons 
sind so direkt nebeneinander auch recht ungünstig angeordnet. Ich verclicke mich da auch öfter mal. Manchmal fällt’s mir noch vor dem Absenden auf, manchmal nicht.
🖖 Живіть довго і процвітайте
PS: Dass man als Autor Bildern keine Größe mehr verpassen kann, ist auch recht ungünstig. Früher ging das mal mit {:width=366}.
Also, wenn es Dir rein darum geht, keine EAN zu verbreiten, dann hast Du ja schon Vorschläge für eine UID oder interne Shop-ID mit ausreichender Sicherheit/Unterscheidbarkeit bekommen.
Stimmt, aber auch unter Zuhilfenahme dieser Vorschläge bräuchte ich ja eine Tabelle, die das verwaltet.
Dann aber kann ich auch den Index nehmen, der erfüllt dieselbe Vorgabe.
Ich weiß ja jetzt nicht, was Deine Kunden für Waren anbieten. z.B. bei manchen Ersatzteilen ist es unumgänglich, die Teilenummer des ursprünglichen Herstellers mit aufzunehmen. („Ersetzt Teilenummer XYZ-0815“), weil damit eine Reihe von Zusicherungen verbunden sind - vor allem die, dass das Teil ohne Umbauten als Ersatzteil verwendbar ist und sodann auch funktioniert.
Es kann also sein, dass eine solche Angabe zwingend ist, weil die Kunden deiner Kunden keine Kunden Deiner Kunden mehr sind, wenn diese Angabe fehlt.
Ja, diese Art Artikel haben meine Kunden massig.
Und diese Informationen fließen natürlich in die Artikeldaten ein.
Was bisher ja auch insofern gut funktionierte, als dass ich beim Import der Artikel erst alle Artikel des Lieferanten gelöscht habe und dann alle neuen eingespielt habe. Somit war der "ersetzte Artikel" nicht mehr über die Artikelsuche verfügbar.
Aber gut, dass Du diesen Punkt ansprichst (so wie Rolf übrigens in einem seiner Postings es auch schon gemacht hat - ich solle nicht vorhandenen Artikel ein del-flag verpassen), den muss ich auf jeden Fall bedenken, wenn statt einer "lösch und insert" Strategie auf eine update-Strategie umsteigen sollte.
Da, wo ich es jetzt schon per update mache, gab es diese Art Artikel nicht, daher musste ich das dort nicht berücksichtigen.
Hello,
Wenn ich mir „was Geniales“ einfallen lasse und dessen Realisierung angehe, dann bin ich mir von Anfang an sicher, dass ich beachtliche Mengen meines eigenen Murkses nach dem Motto „Mist! Wieder was gelernt.” mit der
DEL-Taste verbessere.
Das Unangenehme dabei ist nur, dass sich die eingeengte Sicht auf die Aufgabenstellung bei Hank schon seit 25 Jahren festgefressen hat, wie aus seiner despektierlichen Antwort auf meine Hinweise hervorgeht.
Das liest sich so, als würde er an einer Verschlimmbesserung eines der Shops vom Zoni, den 40Räubern, iBuy, oder so arbeiten.
Glück Auf
Tom vom Berg
wie aus seiner despektierlichen Antwort auf meine Hinweise hervorgeht.
Schau dir meine Antworten auf Rolf an.
Ich versuche mich möglichst meinem Gegenüber anzupassen, was meine Antworten angeht. So auch bei dir.
Hallo Hank,
wenn man das wahrgenommene Niveau seines Gegenübers spiegelt, ist der Eskalationsschmetterling nicht weit.
Sei ein Pfadfinder: mach die Welt mit jedem Posting ein kleines bisschen besser 😀
Rolf
@willi:
Jepp. Bekanntermaßen nützt es herzlich wenig, einer Person - die sich fest zum Scheitern entschlossen hat - von einer Vorgehensweise abbringen zu wollen, welche derart zwingend und also vorhersehbar zum Scheitern führt.
„Hank“ will wohl ein Buch darüber schreiben, wie man es warum nicht macht. Und braucht dazu eigene Negativ-Er
/[gl]/ebnisse statt Be/[kl]/ehrungen.
Womöglich ein Kinderbuch?
Irgendwie überzeugt mich das, liest es sich doch fast, wie eine Antwort von Dir an Habeck. Und wie der will ich nicht sein... 😜
Ich habe es aber anders organisiert und werde nicht umorganisieren,
Das wirst Du müssen.
Falls es Dir darum geht, Aufwand dafür zu vermeiden: An vielen Stellen (vor allem im Besucher-Teil) wirst Du nur die SQL-Abfrage anpassen müssen. Und vielleicht nicht mal die, weil Du eine View anlegen und nutzen kannst.
Der Aufwand und die Unmöglichkeiten, die Dein bisheriges „Ein-Tabellen-Design“ nach sich zieht, wird den der Umstellung krass übersteigen. Und Du wirst an irgendeiner Stelle merken, dass mit der bisherigen Art, die Daten zu organisieren, vieles nicht realisierbar ist.
Ich habe es aber anders organisiert und werde nicht umorganisieren,
Das wirst Du müssen.
Im Grunde ist es nicht so viel Arbeit.
Ich benötige doch nur einen Artikelstamm mit ID, Lieferant und Artikelnummer als Stammdatentabelle.
Meine bisherige Tabelle könnte ich quasi 1:1 beibehalten, wobei dann Lieferant und Artikelnummer redundant vorhanden wären. Ergänz werden könnte dann noich um den Stammdatenindex, müsste aber gar nicht, weil ja auch über Lieferant und Artikelnummer joinbar.
Falls es Dir darum geht, Aufwand dafür zu vermeiden: An vielen Stellen (vor allem im Besucher-Teil) wirst Du nur die SQL-Abfrage anpassen müssen.
Meine Software hat keinen Besucherteil.
Es geht rein um interne Vorgänge und meine Kunden hätten gerne die offiziellen Artikelnummern nur noch in Bestellungen an den Lieferanten oder ggf. in öffentlichen Ausschreibeungen (wenn das Bedingung ist).
In allen anderen Dokumenten könnten dann die eigenen Artikelnummern verwendet werden.
Der Aufwand und die Unmöglichkeiten, die Dein bisheriges „Ein-Tabellen-Design“ nach sich zieht, wird den der Umstellung krass übersteigen. Und Du wirst an irgendeiner Stelle merken, dass mit der bisherigen Art, die Daten zu organisieren, vieles nicht realisierbar ist.
Ist ja schon derzeit kein wirkliches Ein-Tabellen-Modell, da ich ja bereits eine Lagertabelle sowie eine dazugehörige Bewegungsdatentabelle angebunden habe.
Hank
Ist ja schon derzeit kein wirkliches Ein-Tabellen-Modell, da ich ja bereits eine Lagertabelle sowie eine dazugehörige Bewegungsdatentabelle angebunden habe.
Von den anderen ca. 150 Tabellen mal ganz abgesehen.
Eigentlich habe ich alles andere durchnormalisiert.
Es gibt da leider ein paar wenige Baustellen aus frühen Tagen, die mir bekannt sind und die ich mit durchziehe. Liegt daran, dass die Software inzwischen wirklich sehr groß gewachsen ist und jede kleinste Umstellung oft einen riesigen Rattenschwanz an Arbeit und Fehlermöglichkeiten mit sich zieht.
Alleine so eine Änderung von Artikelnummern wirkt sich auf so viele Stellen in der Software aus. Ich weiß nicht, oib mir jetzt auf Anhieb aölle einfacheen, aber vom Artikelstamm über Angebote, Vorgänge, Kalkulation, Bestellwesen, Rechnungseingangwesen, Wareneingang, Faktura inkl. aller Arten von Stornos und Gutschriften bis hin zu E-Rechnungen, und, und, und.
Das ist der Grund, warum ich mit kompletten Umstellungen oft nicht vom ersten tag an "Freund bin".
Hello,
Ist ja schon derzeit kein wirkliches Ein-Tabellen-Modell, da ich ja bereits eine Lagertabelle sowie eine dazugehörige Bewegungsdatentabelle angebunden habe.
Von den anderen ca. 150 Tabellen mal ganz abgesehen.
Eigentlich habe ich alles andere durchnormalisiert.
Wenn es eine Tabelle gibt, in der ID, Artikel, Preis und Lieferant stehen, ist da scheinbar aber nichts normalisiert.
Glück Auf
Tom vom Berg
Ich habe es aber anders organisiert und werde nicht umorganisieren,
Das wirst Du müssen.
Im Grunde ist es nicht so viel Arbeit.
Ich benötige doch nur einen Artikelstamm mit ID, Lieferant und Artikelnummer als Stammdatentabelle.
Meine bisherige Tabelle könnte ich quasi 1:1 beibehalten, wobei dann Lieferant und Artikelnummer redundant vorhanden wären. Ergänz werden könnte dann noich um den Stammdatenindex, müsste aber gar nicht, weil ja auch über Lieferant und Artikelnummer joinbar.Falls es Dir darum geht, Aufwand dafür zu vermeiden: An vielen Stellen (vor allem im Besucher-Teil) wirst Du nur die SQL-Abfrage anpassen müssen.
Meine Software hat keinen Besucherteil.
Es geht rein um interne Vorgänge und meine Kunden hätten gerne die offiziellen Artikelnummern nur noch in Bestellungen an den Lieferanten oder ggf. in öffentlichen Ausschreibeungen (wenn das Bedingung ist).
In allen anderen Dokumenten könnten dann die eigenen Artikelnummern verwendet werden.Der Aufwand und die Unmöglichkeiten, die Dein bisheriges „Ein-Tabellen-Design“ nach sich zieht, wird den der Umstellung krass übersteigen. Und Du wirst an irgendeiner Stelle merken, dass mit der bisherigen Art, die Daten zu organisieren, vieles nicht realisierbar ist.
Ist ja schon derzeit kein wirkliches Ein-Tabellen-Modell, da ich ja bereits eine Lagertabelle sowie eine dazugehörige Bewegungsdatentabelle angebunden habe.
Hank
Na dann wird es Zeit, aus dem “Ich habe es aber anders organisiert und werde nicht umorganisieren,“ ein „Ich schau mir das an.“ zu machen.
Na dann wird es Zeit, aus dem “Ich habe es aber anders organisiert und werde nicht umorganisieren,“ ein „Ich schau mir das an.“ zu machen.
In dieser Phase bin ich bereits.
Und überlege, wie ich mit Änderungen in den Artikeldaten umgehe, bezogen auf den Artikelstamm.
Erste Überlegung:
Ich lege einen Insert-Trigger auf die Artikeldaten.
Dann würde jeder eingetragene Artikel (egal ob manuell oder per Datenimport) automatisch einen Eintrag in der Stammdatentabelle erzeugen.
Zweite Überlegung:
Was mache ich mit Änderungen im Artikelbestand?
Solange die Änderungen nur Artikeldaten und Preis angehen, wirkt sich das auch die Stammdatentabelle gar nicht aus. Eine Artikelhistorie benötige ich nicht.
Aber wenn ein Kunde den Artikel einem neuen Lieferant zuordnet oder aber die Artikelnummer ändert, habe ich ein Problem.
Denn: Mache ich dann in der Stammdatentabelle auch ein Update oder behandle ich es so, als wäre ein komplett neuer Artikel angelegt worden? Eigentlich müsste ich sperren, dass ein angelegter Artikel nochmal den lieferant und/oder die Artikelnummer ändert. Das wäre das sicherste.
Wie seht Ihr das?
Hank
Hello,
[Nachtrag] Google ist schlau:
ich habe im Netz nach einer Funktion in php gesucht, die eindeutige IDs erzeugt, die nur aus Ziffern bestehen.
Wirklich brauchbares habe ich nicht gefunden.
PHP kennt die Funktion uniqid
Nach diesem Vorbild könntest Du auch eine eigene Nummer generieren.
Aber das ist mMn der falsche Ansatz. Eine Artikelnummer sollte durchaus auch Sinn haben. Z. B.:
- WGR = Warengruppe, mnemonisch oder drei bis vier Ziffern.
- Artikelgruppe
- Artikel
- Variante
- Prüfziffer
Beispiel:
KAB-NYM-0525-001-9
Da muss man allerdings inzwischen auch mit der Intelligenz von Google rechnen:
Wobei die Prüfziffer jetzt noch nicht stimmt, die ist frei erfunden.
Diese Nummern sollte man also tatsächlich nur intern verwenden.
Es scheint mir sowieso so zu sein, dass auf den Angeboten und den Rechnungen keine Artikelnummern, sondern
ersscheinen sollten. Die sind dann ohnehin Unique und nicht im Internet zu finden, bestenfalls als Telefonnummer.
Mir scheint es sich hier also immer noch ein Modellierungsproblem bzw. um drei bis fünf ausgelassene Semester beim Wirtschafts(informatik)studium zu handeln.
Glück Auf
Tom vom Berg
Diese Nummern sollte man also tatsächlich nur intern verwenden.
Es scheint mir sowieso so zu sein, dass auf den Angeboten und den Rechnungen keine Artikelnummern, sondern
- Angebots-Positionsnummern
- Rechnungs-Positionsnummern
ersscheinen sollten. Die sind dann ohnehin Unique und nicht im Internet zu finden, bestenfalls als Telefonnummer.
Du hast die Problemstellung bzw. die Kundenanforderung einfach noch nicht verstanden, obwohl ich sie mehrfach angesprochen habe.
Macht aber nichts. 😉
Mir scheint sich hier also immer noch ein Modellierungsproblem bzw. um drei bis fünf ausgelassene Semester beim Wirtschafts(informatik)studium zu handeln.
Na klar, Du mich auch. 😉
Edit: Kann man eigentlich als angemeldeter User hier Antworter aus Threads ausschließen? Oder würde ein Bitte darum auch ausreichen? Dann würde ich Dich, lieber Tom, hiermit darum bitten, Dich zu mienem Thema nicht weiter zu äußern, weil ich Dich als provokant und zugleich als wenig hilfreich empfinde. Danke im Voraus.
Hello,
Edit: Kann man eigentlich als angemeldeter User hier Antworter aus Threads ausschließen? Oder würde ein Bitte darum auch ausreichen? Dann würde ich Dich, lieber Tom, hiermit darum bitten, Dich zu mienem Thema nicht weiter zu äußern, weil ich Dich als provokant und zugleich als wenig hilfreich empfinde. Danke im Voraus.
Wer hat eigentlich Schuld, wenn die Hilfeanbieter:innen die Fragen des/der Hilfesuchenden angeblich nicht verstehen?
Besser ist es sicherlich, substantiiert anzusprechen, was einen stört. Dann kann man Miss- oder Unverständnisse vielleicht schneller aus dem Weg räumen.
Mich stört an Dir deine verbohrte Haltung, die es Dir unmöglich macht, dass Du zunächtst auch eine sogenannte Denkbereichserweiterung zulässt.
Diese Methode ist aber schon so alt, dass noch nicht einmal die allwissende Müllhalde Treffer dazu liefert. Allerdings gibt es in meinem Bücherschrank noch mehrere bis heute gültige Druckwerke zu dem Thema.
Lass es einfach mal zu, dass Andere Dir Vorschläge machen, und lasse Dich zumindest hypothetisch darauf ein. Am Ende kannst Du dann immer noch sagen: "war wohl leider nichts. umsonst den Kopf benutzt!"
Glück Auf
Tom vom Berg
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann.
Mittels Mysql könntest Du eine kleine Extratabelle vorhalten, in der Du Deine Artikelnummern jeweils höchste Artikelnummer verwaltest. Dann kannst Dir eine kleine PHP-Funktion (oder je nach Gusto Stored Procedure) bauen, die Dir bei Bedarf immer eine neue, eindeutige Nummer liefert. Fallstrick dabei sind Race-Conditions.
Dem kann man beispielsweise mit Transaktionen begegnen. Statt Transaktionen würde ich einfach eine Mysql-Funktion verwenden, die das Thema super einfach löst und Dir eine sichere, neue Artikelnummer liefert:
Gunnar Bittersmannmysql> UPDATE sequence SET id=LAST_INSERT_ID(id+1);
mysql> SELECT LAST_INSERT_ID();
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann.
Mittels Mysql könntest Du eine kleine Extratabelle vorhalten, in der Du Deine
Artikelnummernjeweils höchste Artikelnummer verwaltest. Dann kannst Dir eine kleine PHP-Funktion (oder je nach Gusto Stored Procedure) bauen, die Dir bei Bedarf immer eine neue, eindeutige Nummer liefert. Fallstrick dabei sind Race-Conditions.
Ich möchte für Artikel eigene interne Artikelnummern vergeben. So könnte ich Vorgänge (z.b. Angebote) mit Artikelnummer erstellen, die aber vom Kunden nicht gleich im Internet gesucht werden können, ob sie woanders vielleicht billiger sind. Oder vom Mitbewerber, oder, oder...
Am einfachsten wäre es ja, ich könnte die Artikel-ID aus mysql nehmen, weil die ohnehin eindeutig ist. Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dsann die neuen eintrage. Somit würde dann ein- und derselbe Artikel nicht nur einen neuen Preis, sondern auch eine neue interne Artikelnummer erhalten. Das gefällt mir nicht.
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann. Vielleicht könnte ich einen hash aus LieferantenID und Artikelnummer machen? Aber der würde sicher ziemlich lang werden.
Hank
Ich möchte für Artikel eigene interne Artikelnummern vergeben [...]
Zunächst einmal erhöhst Du Deinen Chancen auf Hilfestellung nicht gerade, wenn Du Deine bereits erfolgten Ausführungen stumpf via Copy & Paste wiederholst. Man könnte das auch "unhöflich" nennen.
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann.
Genau darauf hast Du bereits eine Antwort erhalten. Wenn Du dazu Rückfragen / Verständnisprobleme hast, dann frag halt.
Ich möchte für Artikel eigene interne Artikelnummern vergeben [...]
Zunächst einmal erhöhst Du Deinen Chancen auf Hilfestellung nicht gerade, wenn Du Deine bereits erfolgten Ausführungen stumpf via Copy & Paste wiederholst. Man könnte das auch "unhöflich" nennen.
Aber mir fällt auch derzeit nicht ein, wie ich eine immer identische interne und nicht superlange eigene Artikelnummer generieren kann.
Genau darauf hast Du bereits eine Antwort erhalten. Wenn Du dazu Rückfragen / Verständnisprobleme hast, dann frag halt.
Ich wollte nicht unhöflich sein.
Ich hatte und habe den Eindruck, dass Du meine Frage nicht verstanden hast, aber ich weiß nicht, wo ich ansetzen soll.
Deshalb (und weil ich es nicht anders ausdrücken kann) habe ich den Part nochmal eingefügt.
Hank
Hallo Hank,
wir sind durchaus im Stande, auch ältere Postings nochmal zu lesen 😉. Wir lesen zumeist auch Antworten, die andere gegeben haben, bevor wir selbst was schreiben. Schonmal überschneidet sich das und zwei Leute schreiben das Gleiche. Kommt vor.
Du musst also Mitleser nicht neu erklären, was Du Tom schon geschrieben hast - und andersrum.
Ich denke, du hast Dein Problem klargemacht. Du hast mehrere Alternativen bekommen. Die solltest Du jetzt erstmal durchdenken. Trennen von Fremd- und Eigendaten dürfte das Wichtigste sein.
Rolf
Deshalb (und weil ich es nicht anders ausdrücken kann) habe ich den Part nochmal eingefügt.
Vielleicht hätte ich anders fragen sollen:
Ist es möglich, aus einem String mit 10-40 Zeichen einen Integer mit max. 8-10 Zeichen zu machen, der reproduzierbar und möcglichst auch noch unique ist?
Hank
Hallo Hank,
ja, mit md5 oder crc32. md5 liefert einen Hex-String, das ist unangenehm. crc32 liefert einen Integer.
Beides ist eine Form des Hashings.
Aber: bei Hashing-Verfahren ist es zwar selten, aber prinzipiell nicht zu verhindern, dass zwei unterschiedliche Eingaben zum gleichen Hash führen.
Deswegen die von mir beschriebene Kollisionsbehandlung.
Und wenn man eh schon Kollisionen behandeln muss, kann man auch gleich Zufalls-IDs erzeugen. Gute Hashes sind von Zufallszahlen kaum unterscheidbar.
Rolf
Ist es möglich, aus einem String mit 10-40 Zeichen einen Integer mit max. 8-10 Zeichen zu machen, der reproduzierbar und möcglichst auch noch unique ist?
Ich will jetzt nicht viel rechnen.
Integer mit 10 Ziffern (0 bis 9):
10^10
10000000
Variationen.
26 große und kleine Buchstaben, dazu 10 Ziffern. Sind 62 verschiedene Items.
Bei bis zu 40 Zeichen ergeben sich:
62^40
496212362459367066914366580195701544604991251555593230875525121862270976
Variationen.
Ich schätze, die von Rolf erwähnte Kollisionen treten unerwartet oft ein.
Ich schätze, die von Rolf erwähnte Kollisionen treten unerwartet oft ein.
Habe ich befürchtet.
Danke für die Erklärung.
Hank
Hallo Hank,
Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dann die neuen eintrage.
Ja. Das ist das Problem. Wenn man Daten von Dritten einbindet und diese Daten mit eigenen Attributen anreichert, muss man sich überlegen, wie man mit Updates umgeht.
Fremd- und Eigendaten in einer gemeinsamen Tabelle zu speichern ist offensichtlich suboptimal.
Aber Du sagtest ja, dass deine Daten einen eindeutigen Schlüssel haben: Lieferanten-ID und dessen Artikel-ID.
Damit kannst Du Mitlesers Idee aufgreifen: Eine eigene Tabelle, mit Lieferanten-ID, Fremd-ArtikelID und Eigen-ArtikelID. Die Eigen-ArtikelID braucht einen UNIQUE Index, damit Du schnell herausbekommst, ob eine Kollision entsteht.
Nach einem Datenimport musst Du dann ein Script laufen lassen, das die Fremddaten-Tabelle mit der Tabelle für eigene ArtikelIDs verknüpft, und zwar so, dass Du die Fremddaten-Rows bekommst, für die Du noch keine eigene Artikel-ID hast.
select lieferantid, lieferant_artikelid
from lieferantendaten l
where not exist(select * from eigenedaten e
where e.lieferantid = l.lieferantid
and e.lieferant_artikelid = l.lieferant_artikelid)
Das Ergebnis haust Du Dir in ein Array (oder eine Datei, falls Du Millionen von Sätzen hast). Dann läufst Du da drüber. Pro Eintrag
Damit hast Du die Lieferantendaten von deinen eigenen Daten getrennt und kannst deine Preis-Updates wie gehabt per "Abriss und Neubau" einspielen. In der Tabelle für die eigenen Daten kannst Du auch weitere Infos unterbringen, wie Lagerbestand oder andere Infos, die für Dich wichtig sind.
Mit Race-Conditions, wie Mitleser andeutete, solltest Du bei der ID-Generierung kein Problem haben, da Du Preis-Updates ja sicherlich während einer Downtime des Shops einspielst und dann niemand sonst auf der DB ist. Der ID Generator wird beim ersten Mal länger brauchen, weil noch gar keine Eigen-IDs vorhanden sind, aber in den Folgeläufen dürften die meisten Artikel schon da sein und es muss nur wenig angelegt werden.
Rolf
Hallo Rolf,
danke für deine klasse Antwort.
Damit kann ich etwas anfangen, weil sie auführlicher ist und ich so auch die Ansätze der Mitforisten verstehe.
Aber Du sagtest ja, dass deine Daten einen eindeutigen Schlüssel haben: Lieferanten-ID und dessen Artikel-ID.
Davon gehe ich erst einmal aus.
Leider machen auch Lieferanten Fehler und es kam schon vor, dass ich 2 Artikelnummern bei einem Lieferanten hatte.
Damit kannst Du Mitlesers Idee aufgreifen: Eine eigene Tabelle, mit Lieferanten-ID, Fremd-ArtikelID und Eigen-ArtikelID. Die Eigen-ArtikelID braucht einen UNIQUE Index, damit Du schnell herausbekommst, ob eine Kollision entsteht.
Ok.
Nach einem Datenimport musst Du dann ein Script laufen lassen, das die Fremddaten-Tabelle mit der Tabelle für eigene ArtikelIDs verknüpft, und zwar so, dass Du die Fremddaten-Rows bekommst, für die Du noch keine eigene Artikel-ID hast.
Einverstanden.
Pro Eintrag
- Erzeugst Du eine Eigen-ID. Hier musst Du entscheiden, ob die Eigen-ID reine Zufallszahlen sein können (z.B. von 100000 bis 999999) oder ob Du für irgendwas Nummernkreise bilden willst, wie Tom andeutete. Ob Du eine Prüfziffer brauchst, weiß ich nicht, sowas ist eigentlich nur nötig wenn deine Artikelnummern den Computer verlassen und fehlerbehaftet wieder eingegeben werden können.
- Machst Du einen INSERT (lieferantid, lieferant_artikelid, eigen_artikelid) in die Tabelle für die Eigen-IDs. Ist die Eigen-ID schon da, geht der INSERT mit einem DUPLICATE-KEY in die Binsen. Jetzt brauchst Du eine schlaue Möglichkeit, eine neue ID zu finden. Mit der neuen ID wiederholst Du diesen Schritt. Ist der Algorithmus hinreichend schlau, wird es für die meisten Artikel gar keine Kollision geben. Und wenn es eine gibt, dann nicht öfter als ein- oder zweimal. Bau aber eine Kontrolle ein, dass Du maximal 3 Ersatz-IDs erzeugst. Du willst bei einem Bug in der Ersatz-ID Suche nicht in eine Endlosschleife laufen.
Ok.
Damit hast Du die Lieferantendaten von deinen eigenen Daten getrennt und kannst deine Preis-Updates wie gehabt per "Abriss und Neubau" einspielen. In der Tabelle für die eigenen Daten kannst Du auch weitere Infos unterbringen, wie Lagerbestand oder andere Infos, die für Dich wichtig sind.
Muss mal überlegen. Dann habe ich z.b. eine Tabelle "Artikel", eine Tabelle "Intern" und eine Tabelle "Lager" (nur als beispiel). Die sind verbunden über LieferantID und ArtikelNr, also Spalten, die in allen 3 Tabellen zu finden sein werden. (mal unabhängig davon, dass ich in der lagertabelle auch die InternID nutzen könnte).
Aber solange ich die Preise weiterhin in der Artikeltabelle habe, kann ich meine "Abriss und Neubau"-Strategie dann doch nicht weiter führen. Denn wenn ein Artikel beim Lieferanten aus dem Sortiment gestrichen wird, fehlt mir der Eintrag in der Artikeltabelle. Weiterhin fehlen mir Stammdaten. Dann habe ich Lagerbestände zu "Geisterartikeln", nicht wahr?
Mit Race-Conditions, wie Mitleser andeutete, solltest Du bei der ID-Generierung kein Problem haben, da Du Preis-Updates ja sicherlich während einer Downtime des Shops einspielst und dann niemand sonst auf der DB ist. Der ID Generator wird beim ersten Mal länger brauchen, weil noch gar keine Eigen-IDs vorhanden sind, aber in den Folgeläufen dürften die meisten Artikel schon da sein und es muss nur wenig angelegt werden.
Race-Conditions sind unproblematisch, genau wie du sagst.
Hank
Hallo Hank,
Denn wenn ein Artikel beim Lieferanten aus dem Sortiment gestrichen wird, fehlt mir der Eintrag in der Artikeltabelle. Weiterhin fehlen mir Stammdaten. Dann habe ich Lagerbestände zu "Geisterartikeln", nicht wahr?
Tjaaa. Ist das Erstellen eines technischen Konzepts nicht ein toller Job?
Mir scheint, du musst in drei Schritten vorgehen:
Wie wär's, wenn Du die neue Lieferung in eine Temp-Tabelle importierst, statt in deine Stammdaten, und dann ein Update-Script drüberjagst?
Übrigens: wenn man viele Rows importieren muss, ist es oft fixer, Indexe erst zu droppen und dann neu zu erzeugen, statt den Index bei jeder Zeile neu bauen zu lassen. Wenn Du den SQL Server Dateien von Dir lesen lassen kannst, kann auch ein LOAD viel fixer sein als ein Massen-Insert. Ob das von Belang ist, hängt von deinem Datenvolumen ab.
Rolf
Hallo Rolf,
Denn wenn ein Artikel beim Lieferanten aus dem Sortiment gestrichen wird, fehlt mir der Eintrag in der Artikeltabelle. Weiterhin fehlen mir Stammdaten. Dann habe ich Lagerbestände zu "Geisterartikeln", nicht wahr?
Tjaaa. Ist das Erstellen eines technischen Konzepts nicht ein toller Job?
Sag ich ja 😉
Mir scheint, du musst in drei Schritten vorgehen:
Wie wär's, wenn Du die neue Lieferung in eine Temp-Tabelle importierst, statt in deine Stammdaten, und dann ein Update-Script drüberjagst?
Ganz genauso mache ich es jetzt, wenn es ein Lagerartikel ist.
Bei Nicht-Lagerartikeln lösche und schreibe neu, bei Lagerartikeln gehe ich über eine temporäre Tabelle und überschreibe.
So richtig glücklich bin ich aber damit nicht, auch wenn es funktioniert.
Übrigens: wenn man viele Rows importieren muss, ist es oft fixer, Indexe erst zu droppen und dann neu zu erzeugen, statt den Index bei jeder Zeile neu bauen zu lassen. Wenn Du den SQL Server Dateien von Dir lesen lassen kannst, kann auch ein LOAD viel fixer sein als ein Massen-Insert. Ob das von Belang ist, hängt von deinem Datenvolumen ab.
Hierfür habe ich mir ein Script geschrieben, das sich geduldig immer wieder selber aufruft. Das läuft langsam, aber stabil.
Hank
Lieber Hank,
Ganz genauso mache ich es jetzt, wenn es ein Lagerartikel ist.
Bei Nicht-Lagerartikeln lösche und schreibe neu, bei Lagerartikeln gehe ich über eine temporäre Tabelle und überschreibe.
das klingt nach kaputter Logik. Warum sollten „Lager“-Artikel anders behandelt werden, als „nicht-Lager“-Artikel? Offensichtlich wird hier mit Gewalt an einem kaputten Programm festgehalten und liebevoll herumgefrickelt, anstatt es in die Tonne zu treten und „gleich richtig“ zu machen. Insbesondere dann, wenn sich die DB-Struktur als ungünstig herausstellt, solltest Du bei einem so überschaubaren Projekt die DB-Struktur komplett überarbeiten, denn das führt zu Dauerproblemen.
So richtig glücklich bin ich aber damit nicht, auch wenn es funktioniert.
Warum solltest Du nicht glücklich sein, wenn es doch funktioniert? Oder stört Dich genau das kaputte Konzept dahinter, weil Du dann Dein Programm irgendwann doch in die Tonne treten musst, weil es unmöglich wird, komplexere Funktionalitäten dafür zu entwickeln?
Das läuft langsam, aber stabil.
Hmm. Dein „langsam, aber stabil“ klingt wenig vertrauenerweckend. Eher nach einer Zeitbombe. Aber es braucht nun einmal jeder sein Hobby...
Liebe Grüße
Felix Riesterer
Eine eigene Tabelle, mit Lieferanten-ID, Fremd-ArtikelID und Eigen-ArtikelID. Die Eigen-ArtikelID braucht einen UNIQUE Index, damit Du schnell herausbekommst, ob eine Kollision entsteht.
Wozu brauche ich eigentlich eine Eigen-ArtikelID? Eine Artikel-ID reicht doch, das könnte dann meine Primary Index Spalte mit ai sein, dann ist die automatisch immer unique.
Hello,
Eine eigene Tabelle, mit Lieferanten-ID, Fremd-ArtikelID und Eigen-ArtikelID. Die Eigen-ArtikelID braucht einen UNIQUE Index, damit Du schnell herausbekommst, ob eine Kollision entsteht.
Wozu brauche ich eigentlich eine Eigen-ArtikelID? Eine Artikel-ID reicht doch, das könnte dann meine Primary Index Spalte mit ai sein, dann ist die automatisch immer unique.
Solange wir nicht wissen, was Du verkaufst und von wievielen Lieferanten, kann man das nur halbgar beantworten.
Eine eigene Artikelnummer benötigt man i. d. R aber immer, wenn man ähnliche Artikel/Leistungen von mehreren Lieferanten verkauft.
Glück Auf
Tom vom Berg
Hi,
Solange wir nicht wissen, was Du verkaufst und von wievielen Lieferanten, kann man das nur halbgar beantworten.
Eine eigene Artikelnummer benötigt man i. d. R aber immer, wenn man ähnliche Artikel/Leistungen von mehreren Lieferanten verkauft.
Elektroinstallation, mehrere Hundert Lieferanten.
Und die eigene Artikelnummer ist nur dazu da, es dem Kunden schwieriger zu machen, Preisvergleiche anzustellen.
Und ich selber bin auch nicht der Verkäufer, sondern die nutzer meiner Software verkaufen und hätten sowas gerne.
Bisher kann man die Artikelnummer in externen Dokumenten einfach ausblenden.
Das macht es aber auch dem Verkäufer schwer, wenn er selber anhand eines solchen Dokumentes einen Artikel heraussuchen soll. Geht zwar, aber er muss dann in den Originalvorgang und dort nachschauen. Einfacher wäre, wenn er einfach die interne Artikelnummer in die Artikelsuche eingibt und dort fündig wird.
Hank
Hello,
Solange wir nicht wissen, was Du verkaufst und von wievielen Lieferanten, kann man das nur halbgar beantworten.
Eine eigene Artikelnummer benötigt man i. d. R aber immer, wenn man ähnliche Artikel/Leistungen von mehreren Lieferanten verkauft.
Elektroinstallation, mehrere Hundert Lieferanten.
Und die eigene Artikelnummer ist nur dazu da, es dem Kunden schwieriger zu machen, Preisvergleiche anzustellen.
Und ich selber bin auch nicht der Verkäufer, sondern die nutzer meiner Software verkaufen und hätten sowas gerne.
Bisher kann man die Artikelnummer in externen Dokumenten einfach ausblenden.
Das macht es aber auch dem Verkäufer schwer, wenn er selber anhand eines solchen Dokumentes einen Artikel heraussuchen soll. Geht zwar, aber er muss dann in den Originalvorgang und dort nachschauen. Einfacher wäre, wenn er einfach die interne Artikelnummer in die Artikelsuche eingibt und dort fündig wird.
Das liest sich alles sehr ungeplant. Da bedarf es zunächst einer sauberen Modellierung! Hierzu auch nochmals der Verweis auf Normalisierung und auf ein ERM-Diagramm (Entity Relationship Diagramm)
An einem erweiterten Suizid durch schlechte Software mag ich nämlich nicht teilnehmen.
Was haben Preisvergleiche mit Artikelnummern zu tun und was hat eine Käufersicht auf die Daten mit der eigenen (Verkäufer-)Sicht auf die Daten zu tun?
In einem vernünftigen System sieht auch die Verkaufsabteilung nicht die Preise der Einkaufsabteilhng, nur wie weit sie runter gehen dürfen.
Glück Auf
Tom vom Berg
Das liest sich alles sehr ungeplant.
Hab ich in den letzten 25 Jahren schon öfter gehört.
Vielleicht hast Du recht und ich sollte weniger auf meine Kunden und die Sicht aus der Praxis hören.
Was haben Preisvergleiche mit Artikelnummern zu tun und was hat eine Käufersicht auf die Daten mit der eigenen (Verkäufer-)Sicht auf die Daten zu tun?
Stimmt. Was haben Preisvergleiche mit Artikelnummern zu tun? Wie kommen meine Kunden nur ohne jede Absprache aus dem kompletten deutschsprachigen Raum auf dieselben solchen Ideen?
In einem vernünftigen System
Soso, in einem vernüftigem System also.
Ja, auch von denen habe ich in den letzten 25 Jahren einige kennengelernt. 😊
sieht auch die Verkaufsabteilung nicht die Preise der Einkaufsabteilhng, nur wie weit sie runter gehen dürfen.
Du meinst auch hier sicher: Die Verkaufs- und Einkaufsabteilung einer "vernünftigen" Firma? So eine mit Pförtner, Empfangshalle, usw.? 😉
Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dsann die neuen eintrage.
Wieso das denn? Normalerweise hat man die Preise in einer zweiten Tabelle → „Normalisierung“. Dann kann man nämlich auch nachsehen, welcher Preis vor zwei Wochen, ab morgen um 04:30 oder vor einem Jahr galt...
ich habe im Netz nach einer Funktion in php gesucht, die eindeutige IDs erzeugt, die nur aus Ziffern bestehen.
Mal so aus dem Stegreif:
strval( hrtime( true ) ) . strval( rand( 1000000, 9999999 ) )hexdec( uniqid( true ) )Ich habe da mal zwei Fragen an Dich.
Also offensichtlich stehst Du mit Deinen Programmierkenntnissen ganz am Anfang.
Hi,
Hintergrund: Ich möchte für Artikel eigene interne Artikelnummern vergeben. So könnte ich Vorgänge (z.b. Angebote) mit Artikelnummer erstellen, die aber vom Kunden nicht gleich im Internet gesucht werden können, ob sie woanders vielleicht billiger sind. Oder vom Mitbewerber, oder, oder...
also ich lasse mir von Dir ein Angebot für einen Flux-Capacitor geben. Der hat bei Dir die Artikelnummer 4711.
Wenn ich mir dann z.B. bei wolga.eu[1] einen Vergleichspreis raussuchen will, suche ich dort doch nicht nach "4711", sondern nach "Flux-Capacitor".
cu,
Andreas a/k/a MudGuard
oder einem anderen größten Fluß seines Kontinentes ↩︎
Hello,
Hintergrund: Ich möchte für Artikel eigene interne Artikelnummern vergeben. So könnte ich Vorgänge (z.b. Angebote) mit Artikelnummer erstellen, die aber vom Kunden nicht gleich im Internet gesucht werden können, ob sie woanders vielleicht billiger sind. Oder vom Mitbewerber, oder, oder...
also ich lasse mir von Dir ein Angebot für einen Flux-Capacitor geben. Der hat bei Dir die Artikelnummer 4711.
Wenn ich mir dann z.B. bei wolga.eu[^1] einen Vergleichspreis raussuchen will, suche ich dort doch nicht nach "4711", sondern nach "Flux-Capacitor".
YMMD
Ich guck immer erst bei Zoni, dann bei iBuy oder 40Räuber, und wenn ich dann ein Gefühl für den Preis habe und was der Billigmarkt so bietet und ich mehr als ein Teil davon benötige, starte ich eine (kostenlose) Anfrage bei WLW und bekomme meistens echte Profiware zum halben Preis. Das funktioniert aber immer über den Artikeltext und nur äußerst selten über Nummern.
WLW geht natürlich nur, wenn man keine Hauruckzuck-Käufe macht, sondern rechtzeitig plant. Die Antwortzeiten betragen zwischen ein und acht Tagen.
Nach Artikelnummern muss man aber leider meistens suchen, wenn es um Original-Ersatzteile geht. Wir wissen ja nicht wirklich, womit Hank handelt - mit Sukkulenten oder mit Auspuffrohren?
Glück Auf
Tom vom Berg
Hallo MudGuard,
Flux-Capacitor
Guter Hinweis. Der synchro-geschädigte Deutsche sucht nämlich nach einem Fluxkompensator, statt Fluxkondensator, wird nicht fündig und freut sich, wenn er die Artikelnummer suchen kann.
Rolf
Flux-Capacitor
Guter Hinweis. Der synchro-geschädigte Deutsche sucht nämlich nach einem Fluxkompensator, statt Fluxkondensator, wird nicht fündig und freut sich, wenn er die Artikelnummer suchen kann.
Das aber flugs!
@@Rolf B
Flux-Capacitor
Guter Hinweis. Der synchro-geschädigte Deutsche sucht nämlich nach einem Fluxkompensator, statt Fluxkondensator, wird nicht fündig und freut sich, wenn er die Artikelnummer suchen kann.
You made my previous day.
🖖 Живіть довго і процвітайте