Seite 1 von 1

Datenverwaltung von 200.000 Einträgen

Verfasst: 13.02.2012, 12:55
von ElDiablo
Hallo zusammen,

ich habe folgendes Problem.

Mein Datenformat ist eine Preisliste eines Herstellers, die aus ca. 200.000 Zeilen besteht. Es gibt keine Trennzeichen, sondern eine Trennung nach Positionen im String.

Nun möchte ich für jede dieser Zeilen eine Unterseite im Format:
domain.tld/artikelnummer
generieren und diese sauber verknüpfen.

Einige Artikel haben Umschlüsselungen drin, die auf andere Artikel verweisen. (wieder einfach eine Artikelnummer, die mitten im String an einer Position steht)
Andere Artikel haben ein Vermerk für "Sonderbestellungen", die es nur sehr teuer über das Ausland gibt.

Es kann also sein, dass folgende Logiken entstehen

Artikel A (ausverkauft) -> Artikel B (ausverkauft) -> Artikel C (verfügbar)
Artikel A (ausverkauft) -> Artikel B (Sonderbestellung)
Nun will ich natürlich bei der Sucheingabe von A oder B direkt auf C verweisen und dort hinterlegen, dass es der Ersatzartikel ist.

Mehr Infos gibt die Liste eigentlich nicht her .. die Frage wäre:
Wie würdet ihr sie versuchen komplett in den Index zu bekommen?
Eine 100 MB große Sitemap wäre vielleicht etwas viel, oder?

Eine große Logik hinter den Nummern ist nur relativ begrenzt vorhanden.
Einige kann ich darüber packen und ihnen Jahreszahlen zuordnen ... andere hingegen nicht.

Jemand eine Idee, wie man das umsetzen könnte?
Bisher dachte ich an einen Parser, der die Daten trennt und sie direkt in eine MySQL schreibt. Dazu ein Script, welches aus dem Daten statische Seiten erzeugt. Nur die gigantische Anzahl macht mir ein wenig Sorgen.

Freue mich über Anregungen.
Zur Darstellung hab ich an sowas hier gedacht:
https://www.tsep.info/php/cms/

Quasi eine ganz schlanke Startseite á la Google, die dann direkt die Ergebnisse und Preise ausspuckt.

Gruß El

Verfasst:
von

Verfasst: 13.02.2012, 13:41
von Malte Landwehr
Wegen Sitemapgröße: Du kannst in einer Sitemap auf weitere Sitemaps verweisen. Damit bekommst du dann quasi "beliebig" viele Unterseiten in deiner Sitemap, bzw. deinen Sitemaps, unter.

Wegen der Umsetzung: Wozu den Umweg über MySQL gehen? Je nach dem, mit welcher Programmiersprache du das ganze machst, kannst du dir das sparen und direkt aus der Liste die statischen Seiten generieren. 200.000 Zeilen ist nicht gerade viel.

Und wozu brauchst du ein CMS, wenn du eh statisch Seiten erzeugen willst?

Verfasst: 13.02.2012, 14:39
von ElDiablo
Hi Malte,

ich bin noch nicht sicher, wie ich da eine logische Aufteilung machen soll, da die Liste einfach alphabetisch sortiert ist. Also könnte ich maximal nach 0..9 / a..z "Untersitemaps" machen. Das wären dann vielleicht nur noch 5-10k Einträge pro Sitemap.

Die Datenbank wollte ich verwenden, da die Updates so ggfs. schnell eingespielt werden könnten. Wollte ungern 200.000 Dateien offline generieren, packen, hochspielen und wieder entpacken. Die einzelne Textdatei einzuspielen und kurz nen Update-Link aufzurufen wäre da die bequemere Lösung.

Wie würdest Du das denn aufbauen? Grad wenn ich eine 2. Liste mit Artikelnummern und Shop-Links hinterlegen will, wäre es in der Form schon ganz nett. Ein gewisser Teil der Artikel ist bei mir im Onlineshop - diese würd ich gern verlinken.

Gruß

Verfasst:
von
SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002
  • persönliche Betreuung
  • individuelle Beratung
  • kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.


Verfasst: 13.02.2012, 15:02
von Nicos
Du solltest NICHT über 5K gehen! ;-)

Verfasst: 13.02.2012, 15:45
von ElDiablo
Da die Verteilung sicher nicht gleichmäßig wird, gäb das schon ein kleines Problem :wink:

Aber bevor ich die Daten nicht komplett eingelesen und geparsed hab, kann ich eh noch nicht sage, welche Artikel wirlich über bleiben und was umgeschlüsselt ist.

Verfasst: 15.02.2012, 10:27
von nerd
Am besten via mysql direkt einlesen wenn du zellen- und zeilentrennzeichen in deiner liste kennst:

https://dev.mysql.com/doc/refman/5.1/en/load-data.html

damit geht das eigentlich immer recht fix; 350MB/60.000 datensaetze in weniger als einer minute hier bei mir.