Database-ontwerp: jullie ideeen?

[nielsgeode]

Met databases ben ik relatief newbie en dit draadje is bedoelt om over langere tijd in de praktijk te brengen. Ik wil mijn database-skills vergroten maar hier gaat flink wat tijd inzitten.

Ik ben al een jaar of 25 fanatiek verzamelaar van mineralen en houd vanaf het begin een simple database in access bij. Ik prober daarbij af en toe tabellen bij te werken om dinge te verbeteren. Van twee onderdelen vraag ik mij af of het anders / beter kan en hoor daar graag jullie ideee over.

De database heeft een table 'collection' met daarin 1 record per collectiestuk. Daarin staan o.a. dingen als wanneer gevonden, wanneer gekocht, aankoopprijs, vindplaats en welke mineralen er aanwezig zijn.

1) Ik heb een table mineralen met daarin 1 record per mineral (van alles wat bekend is). Omdat 1 stuk meerdere mineralen kan bevatten heb ik een tweede table met daarin slechts 2 velden: collectie-id en mineraal-id. Als collectiestuk 3417 dan twee mineralen bevat zijn er 2 records in die table met beiden 3417 als collectie-id met de bijbehorende mineral-id's. Kan dit niet eleganter?

Een bijbehorend ding hier is: wel en niet officieel door de IMA (International Mineralogical Association) erkende mineralen . Simpel voorbeeld: kwarts is erkend, amethyst lijkt chemisch zoveel op kwarts dat het geen aparte soort is maar een variëteit. Voor de telling van het aantal soorten maakt dit uit en als je wel amethyst in je collectie hebt maar geen kwarts en je wilt gaan tellen dan kan je kwarts meetellen als soort ondanks dat het niet direct in de collectie zit. Ik heb hier (nog) geen goede oplossing voor.


2) Ik heb een table vindplaatsen. Hierin staat elke vindplaats 'voluit'. Dus een record:
Winterswijk, Gelderland, Nederland
maar ook een record met:
Gelderland, Nederland
(voor de stukken waar alleen de provincie (gebied) als vindplaats bekend is.)
Het zou mooi zijn om het zo op te slaan dat je kan selecteren op Gelderland en dat ook alle 'ondervindplaatsen' meegenomen worden. Ook hier heb ik nog geen oplossing voor.

3) (wil ik toch nog toevoegen). Ik fotografeer mijn stukken ook en sla de bestanden los op met als eerste altijd het nummer van het stuk in de bestandsnaam (bv 03417 en 00839: die 0 is voor de sortering van de files handig). Is er een handige manier om snel foto's te zien zonder ze handmatig te hoeven linken, dus dat er automatisch recursive in meerdere mappen gezocht wordt op alle jpeg's die met dat #id beginnen?

Er is (vast) nog meer, maar dit moet in stapjes met een collectie van 5000 stukken

[ Voor 108% gewijzigd door nielsgeode op 25-11-2018 21:46 ]

[The Eagle]

Heel eerlijk: doe geen moeite. We prutsen zelf allemaal en als je een eigen blog bij wilt houden over je reilen en zeilen is daar tweakblogs voor.

Heb je een concrete vraag of een wil je een discussie aanzwengelen, dan is het forum wel de juiste plek

Protip: kijk naar normalisatie, en doe wat simpele trainingen op W3C, Udemy of vergelijkbaar, desnoods youtube. Prima te volgen allemaal, steek je veel meer van op dan van een boek lezen

[ Voor 27% gewijzigd door The Eagle op 25-11-2018 21:19 ]

[MAX3400]

Access

Geen idee of je er al een heel front-end omheen hebt gebouwd maar als je wat skills wil verbeteren; tover je huidige database om naar een "algemener" type zoals MariaDB, Microsoft SQL of iets vergelijkbaars.

Het probleem / oplossing begint al met je laatste alinea; er zijn vast nog meer zaken maar die heb je niet paraat / inzichtelijk. Dan is elk ontwerp of aanpassing giswerk en komt het nooit 100% af. Een goed design begint bij alle records, relaties, ideeen, etc. op papier hebben (desnoods letterlijk op papier) en van daaruit een aangepaste / nieuwe opzet maken.

[nielsgeode]

MAX3400 schreef op zondag 25 november 2018 @ 21:40:
[...]

Geen idee of je er al een heel front-end omheen hebt gebouwd maar als je wat skills wil verbeteren; tover je huidige database om naar een "algemener" type zoals MariaDB, Microsoft SQL of iets vergelijkbaars.

Het probleem / oplossing begint al met je laatste alinea; er zijn vast nog meer zaken maar die heb je niet paraat / inzichtelijk. Dan is elk ontwerp of aanpassing giswerk en komt het nooit 100% af. Een goed design begint bij alle records, relaties, ideeen, etc. op papier hebben (desnoods letterlijk op papier) en van daaruit een aangepaste / nieuwe opzet maken.

Nog geen front-end. Ik doe nieuwe input gewoon met standard accessformuliertjes. Het is niet ideaal maar het werkt.Los van welke software je gebruikt (waarom geen access?) blijven mijn OP-vragen staan natuurlijk.

Het moet wel leuk blijven ook. Ik ben verzamelaar, geen IT-er en ga geen jaar lang 20 uur per week stoppen in skills bijleren.

[ Voor 6% gewijzigd door nielsgeode op 25-11-2018 21:43 ]

[MAX3400]

Punt 2 is simpel doch lastig. Kopieer de hele Bos-atlas naar je database? Alle plaatsnamen en alle provincies. Of je gaat het per keer aanvullen maar wat is de volgende stap? Internationaal in Europa? Internationaal per continent?

[nielsgeode]

MAX3400 schreef op zondag 25 november 2018 @ 21:45:
Punt 2 is simpel doch lastig. Kopieer de hele Bos-atlas naar je database? Alle plaatsnamen en alle provincies. Of je gaat het per keer aanvullen maar wat is de volgende stap? Internationaal in Europa? Internationaal per continent?

Voor de eenvoud heb ik even alleen NL gebruikt in het voorbeeld. In werkelijkheid zitten er mijn mijn table al zeker 100 landen en 3000 vindplaatsen… Vindplaatsen waar ik geen enkel collectiestuk van heb hoeven ook niet perse in de database, dat heb ik nu ook niet. Als ik een nieuw stuk in mijn collectie stop en de vindplaats staat er nog niet in dan voeg ik die dan wel toe.


Mindat.org (de grootste mineralendatabase-website) heeft vele tienduizenden zo niet honderdduizend vindplaatsen.

[ Voor 27% gewijzigd door nielsgeode op 25-11-2018 21:50 ]

[Haan]

nielsgeode schreef op zondag 25 november 2018 @ 21:12:
1) Ik heb een table mineralen met daarin 1 record per mineral (van alles wat bekend is). Omdat 1 stuk meerdere mineralen kan bevatten heb ik een tweede table met daarin slechts 2 velden: collectie-id en mineraal-id. Als collectiestuk 3417 dan twee mineralen bevat zijn er 2 records in die table met beiden 3417 als collectie-id met de bijbehorende mineral-id's. Kan dit niet eleganter?

Omdat hier nog niet op gereageerd is: dit is juist hoe het moet Je hebt een M:N (many-to-many) relatie tussen mineralen en jouw collectie tabel, die je door middel van een koppeltabel aan elkaar verbindt.
[quote]

[Mugwump]

Wat betreft je vindplaatsen is de gebruikelijke methode voor een dergelijke hiërarchie om de boel op te slaan in een boomstructuur. Hier heb je bijvoorbeeld een vrij uitgebreid stuk over hoe dat kan in Access:
https://www.experts-excha...Hierachies-in-Access.html

Als je gewoon een vaste structuur hebt kan het ook wel wat praktischer. Neem in je tabel een veld land, provincie, plaats of iets dergelijks.

Voor Gelderland laat je de plaats dan gewoon leeg en bij het zoeken zoek je op provincie = Gelderland.

Nog mooier zou queryen op coördinaten zijn, maar dat ondersteunt Access niet.

[nielsgeode]

Mugwump schreef op maandag 26 november 2018 @ 21:56:
Wat betreft je vindplaatsen is de gebruikelijke methode voor een dergelijke hiërarchie om de boel op te slaan in een boomstructuur. Hier heb je bijvoorbeeld een vrij uitgebreid stuk over hoe dat kan in Access:
https://www.experts-excha...Hierachies-in-Access.html

Als je gewoon een vaste structuur hebt kan het ook wel wat praktischer. Neem in je tabel een veld land, provincie, plaats of iets dergelijks.

Voor Gelderland laat je de plaats dan gewoon leeg en bij het zoeken zoek je op provincie = Gelderland.

Nog mooier zou queryen op coördinaten zijn, maar dat ondersteunt Access niet.

Vaste structuur is geen optie.maar zo'n hierarchy is best interessant. Het aantal sub-localities wisselt teveel en met vaste structuur creeer je ook een maximum. Voorbeeldje: Koktokay pegmatite field (Keketuohai pegmatite field), Fuyun Co. (Koktokay Co.), Aletai Prefecture (Altay Prefecture), Yili Hasake Autonomous Prefecture (Ili Kazakh Autonomous Prefecture), Xinjiang Autonomous Region, China.

Om het om te bouwen ben je wel even bezig denk ik. Voor in de toekomst een leuk idee Ben wel bang dat het aanpassen / managen en wijzigen een grote chaos kan worden. Ik bedoel: vindplaatsen en hierarchy willen nog wel eens wijzigen op mindat. Er wordt bijvoorbeeld een sub-gebied weggelaten of toegevoegd (bijvoorbeeld Twente, hoewel dit alleen buiten Nederland/Europa veel gebeurt). Afrikaanse landen/gebieden wijzigen ook nog wel eens.

En inderdaad iets met een interactieve map is best heel leuk. Ik zou een manier moeten vinden om de data automatisch in lightroom te krijgen (handmatig is geen optie) zodat ik daar ook kan filteren en de map met foto-coordinaten (als vindplaatsen) kan gebruiken. Mijn echte database blijft dan primair en lightroomdata secundair als handig tooltje.

[ Voor 9% gewijzigd door nielsgeode op 26-11-2018 22:29 ]

[The Eagle]

Als ik dit zo lees dan zou ik je eigenlijk willen aanraden eens naar Elasticsearch te kijken. Dat werkt verblufend handig voor dit soort dingen. Kan ook veel groter schalen, maar dat hoeft hier nu uiteraard niet

Met simpelweg wat curl commando's pomp je het er in en er uit. Kun je je hele huidige excel zo ineens mee vullen qua commando's.

Zie verder ook https://github.com/tether...i-mineral-observation-map en https://github.com/tether...on-map/tree/master/ingest voor wat voorbeelden. Hopelijk kun je er iets mee

[HansvDr]

nielsgeode schreef op zondag 25 november 2018 @ 21:12:

1)...

Een bijbehorend ding hier is: wel en niet officieel door de IMA (International Mineralogical Association) erkende mineralen . Simpel voorbeeld: kwarts is erkend, amethyst lijkt chemisch zoveel op kwarts dat het geen aparte soort is maar een variëteit. Voor de telling van het aantal soorten maakt dit uit en als je wel amethyst in je collectie hebt maar geen kwarts en je wilt gaan tellen dan kan je kwarts meetellen als soort ondanks dat het niet direct in de collectie zit. Ik heb hier (nog) geen goede oplossing voor.

Je zou in de tabel mineralen een varieteit_id kunnen opnemen. Deze is 0 (of lager of leeg) als het geen variëteit is. Anders het id waar het een variëteit van is.

[nielsgeode]

HansvDr schreef op woensdag 28 november 2018 @ 13:23:
[...]


Je zou in de tabel mineralen een varieteit_id kunnen opnemen. Deze is 0 (of lager of leeg) als het geen variëteit is. Anders het id waar het een variëteit van is.

Zou prima kunnen werken, behalve in de volgende situaties: lang niet elke soort is even makkelijk te determineren, soms onmogelijk zonder spectroscopische technieken. Er zijn veel verwante soorten met als naam: soortnaam-(X) waarbij de soortnaam steeds gelijk is en X een metaalion waarbij er meerdere aparte soorten bekend zijn. Een voorbeeld is Gmelinite-(Ca), Gmelinite-(K), Gmelinite-(Na) (Ca = calcium, K = kalium, Na = natrium). Gmelinite zonder toevoeging van het metaalion is dan één van die drie soorten omdat niet bekend is welke van de drie een specimen is. Gmelinite moet dan naar alledrie tegelijk verwijzen (Ca, K, Na).

[Killemov]

2) Sla in ieder geval de geolocatie op als vindplaats. Daarmee kun je al het andere afleiden ... mits je geen maan/marssteen o.i.d. in je collectie verwacht natuurlijk.