WinFuture-Forum.de: [mySQL] sammelkarten-db - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Entwicklung
Seite 1 von 1

[mySQL] sammelkarten-db


#1 Mitglied ist offline   CaNNoN 

  • Gruppe: aktive Mitglieder
  • Beiträge: 188
  • Beigetreten: 16. November 05
  • Reputation: 3

geschrieben 08. Oktober 2014 - 13:49

hallo,
nachdem ich ein alter sammler bin und langsam den ueberblick verliere, muss ordnung her.

jetzt stehe ich aber vor folgendem problem:

die karten sind unterteilt in div. serien, allerdings gibt es in etlichen serien mehrere versionen der gleichen karte (d.h. nr. 120/122 in normal, holo, besonderer aufdruck, etc.), außerdem kommen x versch. sprachversionen (d.h. titel der karte aendert sich) hinzu. dem nicht genug gibt es nicht alle karten einer serie in jeder sprachausgabe. (d.h. serie xy hat auf deutsch 122 karten, in einer anderen sprache aber nur 80)

nachdem wir hier von ueber 60 serien sprechen, moechte ich mir das nun natuerlich ersparen, dass ich fuer jede serie in jeder sprache eine eigene tabelle und fuer jede kartenvariante einen eigenen eintrag anlege, ansonsten werde ich gar nicht mehr fertig.

vllt. hat ja jemand eine brauchbare idee fuer derartige db-struktur :-)

lg
0

Anzeige



#2 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.490
  • Beigetreten: 20. Juli 07
  • Reputation: 1.017

geschrieben 08. Oktober 2014 - 14:31

Naja, eine Struktur läßt sich dafür auf jeden Fall entwerfen. So groß ist das ja nicht. Nur, was soll die Datenbank dann leisten - oder anders formuliert, was soll sie ausspucken? :unsure:

So wie ich den Fall grad überblicke, bräuchtest Du:

- Eine Tabelle SERIE für die Serien.
- Eine Tabelle SPRACHE für... genau, die Sprachen. :)
- Zwei Tabellen KARTEN und KARTENTYP, wobei KARTEN für die Karten ist und KARTENTYP für Dinge wie "Holo", "besonderer Aufdruck" und so weiter.

SERIE hätte hier einen zweiteiligen Primärschlüssel (*) aus (serie_id, sprache_id), damit "dieselbe Serie" unter verschiedenen Sprachen eingetragen werden kann. Hier käme dann auch sowas wie "Kartenanzahl" rein.

Bei KARTEN überleg ich grad ein bißchen, aber ohne mir jetzt groß was zusammenzumalen, würde ich meinen, KARTEN braucht einen vierteiligen Primärschlüssel aus (karte_nummer, serie_id, sprache_id, kartentyp_id); aber ich bin mir fast 100%ig sicher, daß man das noch ein bißchen eingestampft kriegt.


Allerdings müßtest Du natürlich sämtliche Daten trotzdem irgendwie in die Datenbank füttern. Klar, die einzelnen Sprachen, Seriennamen (und ggf andere sprachbezogenen Serieneigenschaften) sowie die Kartentypen lassen sich recht schnell in die Datenbank füttern. Aber die einzelnen Einträge wollen ja noch miteinander verbunden werden - "Karte #1 hat Sprache DE, Serie 5, Nummer 112 und die Eigenschaft, "holo" zu sein" kann man auch nur eins nach dem anderen für sämtliche Karten durchgehen.


Weitere Attribute müßten dann halt spezifisch dorthin, wo sie - um doof zu klingen - hingehören (was leider bei DBMS auch gern mal vergessen wird). Serieneigenschaften zur SERIE und NICHT in die KARTEN; Karteneigenschaften zur KARTE und NICHT zur SERIE. Wenn in die Datenbank der "Ablageort" eingetragen wird und Serien alle beisammenliegen, kommt Attribut "hier_liegt_das_Zeug" in die Tabelle SERIE"; wenn Karten eher verteilt rumliegen, bekommt eben KARTE dieses Attribut.


Für alles weitere müßte man halt schauen, was die Datenbank am Ende leisten soll - was sie beantworten können muß. Daraus ergeben sich ggf. weitere erforderliche Attribute.

===
(*) Wenn man's ganz besonders sauber haben will, legt man auch noch Tabellen an für die Serien- und die Karten-"Stammdaten", also alles das, was Serien-/Karteneigenschaften sind, die aber NICHT sprachabhängig sind. "Anzahl_der_Karten" hat daher hier NICHTS zu suchen, wohl aber - als Beispiel - eine Kategorie (sagen wir, "Autos"), deren Bezeichner zwar möglicherweise sprachabhängig sein könnte, aber schlußendlich trotzdem diese Dinger mit drei oder mehr Rädern drunter bezeichnet.


NB. Alle Angaben verstehen sich ohne Gewähr. Für einen genaueren Entwurf müßte man dann schon ein bißchen mehr Zeit und Aufwand investieren, als ich das grad hab; dieser Entwurf ist grad so ein bißchen an den Haaren herbeigezogen. :)

Dieser Beitrag wurde von RalphS bearbeitet: 08. Oktober 2014 - 14:37

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#3 Mitglied ist offline   CaNNoN 

  • Gruppe: aktive Mitglieder
  • Beiträge: 188
  • Beigetreten: 16. November 05
  • Reputation: 3

geschrieben 21. Oktober 2014 - 01:43

hallo ralph,
sorry fuer die spaete antwort, hatte leider bisweilen keine zeit mehr mich damit weiterzubefassen.

koennen muss die db eigentlich "nicht viel" - in meinem ersten entwurf hatte ich die sache so geloest, dass ich je serie eine tabelle mit angaben wie name, nummer, sprache, edition, front- und back-cover hatte, als ausgabe dann jeweils alle karten einer serie auf einer einfachen testpage. nur hatte es mich dann eben in puncto sprache und "versch. ausfuehrung trotz selber nummer" aufgestellt.

wenn ich dich jetzt richtig verstanden habe, dann muesste das in etwa wie folgt aussehen:

table serie
- serie_id (primary)
- sprache_id (primary) (verlinkt mit sprache.sprache_id)
- kartenanzahl je serie (z.b. 64)
- name je serie (z.b. basisset)

table sprache
- sprache_id (primary)
- sprache (z.b. deutsch, englisch, ...)

table karten
- karten_nr (primary) (z.b. 15)
- serie_id (primary) (verlinkt mit serie.serie_id)
- sprache_id (primary) (verlinkt mit sprache.sprache_id)
- kartentyp_id (primary) (verlinkt mit kartentyp.kartentyp_id)
- front_cover_xy (z.b. $serie/$sprache/$karten_nr.png)
- back_cover_xy (z.b. $serie/$sprache/back.png)
/edit: - kartenname_de (z.b. "supertrank")
/edit: - kartenname_en (z.b. "superpotion")
/edit: - kartenname_xy

table kartentyp
- kartentyp_id (primary)
- kartentyp (z.b. reverse)

moeglich, dass es an der uhrzeit liegt (;-)), aber ich kann mir gerade ueberhaupt keinen reim darauf machen wo ich jetzt z.b. die jeweiligen kartennamen hinterlegen soll bzw. wie?
sagen wir: basisset, #15/64, kartenname_de, kartenname_en, kartenname_fr, kartenname_xy

/edit: nochmal drueber nachgedacht - die ganzen kartennamen muessten vermutlich je sprache in die karten-tabelle *facepalm* - dann ist mir allerdings der sprachen table ein raetsel, da ich das ja dann weglassen und einfach nach xy bei kartenname_xy und front/back-cover_xy filtern koennte?

unterm strich waere mein ziel wieder eine einfache webausgabe in der ich via link innerhalb der serie zw. den einzelnen sprachen und innerhalb dieser zw. den einzelnen editionen wechseln kann, will heißen "set 1, englisch, reverse" usw.

besten dank und lg :-)

Dieser Beitrag wurde von CaNNoN bearbeitet: 21. Oktober 2014 - 02:45

0

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.490
  • Beigetreten: 20. Juli 07
  • Reputation: 1.017

geschrieben 21. Oktober 2014 - 14:49

... Bin ich mir grad gar nicht sicher, wo ich das angedacht hatte. :blush: Hatte ja, weil ich faul war <_<, nur ganz wenig Attribute zugeordnet. ^_^

Glaub ja. Sieht aus, als hätt ich das wirklich in die "Karte" gesteckt. Aber da kommt das eigentlich nicht hin. :blush:

Es müßte halt eine Tabelle sein, wo (karte_id, sprache_id, eigenschaft_id) Primärschlüssel ist und dann kommen da halt die lokalisierten Karteneigenschaften rein. Mir war ja grad so, als hätt ich das schon irgendwo geschrieben gehabt... aber mh, vielleicht werf ich's grad mit den Serien zusammen. :unsure:

Jedenfalls, die fragliche Tabelle "Karten_Lokalisiert" hätte dann so Einträge wie (1, 1031, Herstellungsdatum, 1429-10-01) für (karte_id, sprache_id, eigenschaft_name, eigenschaft_wert) - in diesem Beispiel dann halt die Karte #1 in 'deutsch'er Variation, mit dem entsprechenden Name/Wert-Paar. ... Wobei man natürlich, für fixe Eigenschaften, genaugenommen noch eine "standardisierte" Tabelle für die Eigenschaften bräuchte (prop_id, lang_id, ...) und dann statt "eigenschaft_name" stattdessen prop_id in der "Karten_lokalisiert" Definition. Was den Vorteil hat, daß Du dann auch danach suchen kannst, denn DEUTSCHE Karten hätten sonst ein "Herstellungsdatum" und englische irgendwas anderes und französische WIEDER was anderes, so findest Du die anders-sprachigen also nicht.



Bei der "Karte"ntabelle kann es auch rein. Dann wird das aber fehleranfällig, wenn man über selber einzutragende Schlüssel verknüpft. Dann findest Du aber ganz schnell zwanzig Versionen DERSELBEN Karte in der Datenbank, einfach deswegen weil die anderen neunzehn ANDERS verlinkt waren (wegen abweichender Schreibweise/Schreibfehlern/XXX). Deswegen ja der ganze Aufwand, damit das nicht passiert.

(Ganz abgesehen davon, daß in KARTE jede Karte nur maximal EINE Eigenschaft haben dürfte. Das ist vielleicht etwas wenig. :D)

Dieser Beitrag wurde von RalphS bearbeitet: 21. Oktober 2014 - 14:52

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0