too many indexes

Hallo, ik ben als groentje zelf aan de slag gegaan met een database voor het bijhouden van karakteristieken van monumenten. Ik heb zeer veel velden in één van mijn tabellen, waarvan een groot aantal gevuld obv een lookup waarde uit subtabellen. Hoewel deze tabel slechts één echte index heeft (nl. ID), krijg ik toch de foutmelding 'too many indexes'.

Ik heb gelezen dat access hidden indexes toevoegt ingeval je een relatie definieert met 'referential integrity'. Ik had dit initieel bij veel relaties aangezet, maar heb het ondertussen weer overal verwijderd na de foutmelding. Jammer genoeg blijft de foutmelding. Dus wellicht is er ergens nog iets blijven hangen. Heb alleen geen idee hoe ik dit weer boven water moet krijgen.

PS: ik las op andere fora vaak het comment dat dit probleem meestal het gevolg is van een fout database design. Ik heb echter vooraf goed nagedacht over normalisatie, en ik denk dat er momenteel geen redundancy is. Ik heb gewoon heel veel karakteristieken per gebouw...

Allereerst welkom bij HelpMij! Dat je van normalisatie gehoord hebt is een goede zaak, of je het correct hebt toegepast een tweede.

Erfgoedstudio zei:

Ik heb zeer veel velden in één van mijn tabellen, waarvan een groot aantal gevuld obv een lookup waarde uit subtabellen.

Klik om te vergroten...

Met Opzoekvelden (ik richt mij hierbij op de Nederlandstalige lezers ) bedoel je vermoedelijk dat je keuzelijsten in de tabel hebt gemaakt die waarden ophalen uit andere tabellen. Mijn advies: begin opnieuw met je tabel, en gooi ze er allemaal uit. Je kunt de velden ook weer omzetten naar tekstvelden, dat scheelt vermoedelijk ook al een hoop werk. Keuzelijsten horen niet in een tabel thuis, maar op formulieren.

Daarnaast hebben tabellen inderdaad de beperking dat er maximaal 32 indexen per tabel mogen zijn. Zoveel heb ik er nog nooit nodig gehad, en ik snap niet dat jij daar wel aan komt. Dan klopt er volgens mij toch iets niet aan je ontwerp. Als je een tabel op de juiste manier aan een andere tabel koppelt (altijd met Referentiële Integriteit!) dan krijg je nooit een (al dan niet verborgen) index. Maar het feit dat je blijkbaar zoveel ‘eigenschappen’ van een monument in 1 tabel zet, wekt bij mij de indruk dat er een verkeerd ontwerp is gemaakt.
Het lijkt mij dus handig als je dat ontwerp meepost, dan kunnen we daar een blik op werpen.

Allereerst bedankt voor je antwoord! Ik heb al uren gezocht op internet, maar het is fijn dat er nu eens iemand iets terugzegt

De lookup velden zijn bedoeld om de input te vergemakkelijken. Als ik je goed begrijp, stel jij voor om deze niet toe toe voegen in de tabel zelf, maar enkel in het formulier. Dat betekent dan wellicht dat men niet makkelijk rechtstreeks in de tabel kan inputten - wat ik nu wel toe om snel wat testdata in te brengen. Maar in een doorsnee situatie zal dat niet het geval zijn. Dus zal daar alvast eens mee beginnen.

Wat je vraag naar het doorsturen van het ontwerp betreft: graag! Al heb ik geen idee wat voor jullie het meest nuttig is. Heb een aantal tools gezien om de database te documenteren. Kan hiervan iets dienen? Of liever iets anders? Zoals gezegd: ben echt wel een groentje

Grz,
Do.

Ook met een heel "plat" overzichtelijk formulier vul je via het formulier de tabel meteen in...
Het is echter veel veiliger om zo te werken dan rechtstreeks maar ook overzichtelijker dan in de tabel.
Ga vooral verder waar je met OctaFish gebleven was, mocht me nog iets te binnen schieten dan laten ik wel weten.
En zip de database anders even en zet hem hier neer als je niet weet hoe je het ontwerp 1-2-3 moet verwoorden.

Erfgoedstudio zei:

Dat betekent dan wellicht dat men niet makkelijk rechtstreeks in de tabel kan inputten

Klik om te vergroten...

‘Inputten’ staat volgens mij niet in de Van Dale, ‘invoeren’ daarentegen wel . Maar zoals route99 ook zegt: het is veel veiliger om niet rechtstreeks in een tabel in te voeren. En dat geldt zeker voor gewone gebruikers van het systeem. Als beheerder mag dat natuurlijk wel. De belangrijkste reden vind ik: in een tabel moet je altijd de echte waarden kunnen zien. Wat er dus echt in is opgeslagen. En geen aliassen uit andere velden uit andere tabellen.
Gemakzucht mag ook nooit het uitgangspunt zijn bij het ontwerp van een systeem.

Tot zover de standjes . Wat betreft de documentatie: we hebben het meest aan een kopie van de database, zonder gevoelige (persoons)informatie. Daar hoeven ook niet veel (dummy)records in te zitten, maar genoeg om de bedoeling van het systeem te kunnen snappen. Die database kun je dan comprimeren en daarna zippen, dan kunnen wij hem verder weer uitpakken.
Nog een tip: sla vooral geen afbeeldingen op binnen de database, ook al heeft Access (ook) daar velden voor. Het klikt wellicht gek, maar de makers van Access hebben geen flauw benul van wat een database is, en ze bouwen de meest fantastische onzin in het pakket in, en onwetende gebruikers denken vervolgens dat ze die nog moeten gebruiken ook, met alle gevolgen van dien.

Altijd fijn, een taalpurist... zal mijn woorden in het vervolg zorgvuldiger kiezen

Ik weet niet goed welke versie ik je moet doorsturen, want mijn oorspronkelijk ontwerp, met al die 'opzoekvelden' in de tabel zelf, is fout. Daarvan ben ik ondertussen overtuigd (hoewel ik niet snap dat Access dit dan zo makkelijk maakt). Mijn nieuwe versie staat een beetje 'op wacht' tot ik zeker weet dat ik met die veelheid aan velden veilig aan de slag kan. Ik heb wel al een nieuwe tabel gemaakt, met een beperkt aantal velden en dan de 'opzoekvelden' in het formulier, bij wijze van test. En dat lukt alvast.

Het is eigenlijk een heel simpele databank. Misschien volstaat een beschrijving...?

Ik heb slechts 2 'echte' tabellen:
1. alle 'relicten' van de inventaris van bouwkundig erfgoed, met daarin een aantal identicatievelden zoals unieke nummer, straat, huisnummer, deelgemeente, gemeente, provincie, datering gebouw, typologie gebouw, ... Het gros van deze velden zijn waarden die ik onderhoud in subtabellen die de opzoekvelden moeten bevolken.
2. alle (deel)gebouwen van die relicten, met relatie naar het relict, type deelgebouw, en dan een hele boel karakteristieken van het gebouw. Van het dak (origineel of niet, dakvorm, dakbedekking, dakkleur), de gevel (origineel of niet, type pleister, kleur, type plint, type voegen,...), de dakgoten, de waterafvoer, het schrijnwerk enz. En dan een resem karakteristieken mbt de herkenbaarheid, zeldzaamheid, representativiteit, stedebouwkundige eigenschappen,... Ook hier zijn bijna alle velden te baseren op subtabellen waarin ik de masterdata (sorry, kom niet direct op een NL alternatief) wil onderhouden.

Gewoon een hele boel velden dus, die allemaal samen een (deel)gebouw, en daarvan afgeleid een relict, karakteriseren. Ik weet niet of jullie zich op basis hiervan alvast een idee kunnen vormen? Zoals eerder gezegd, heb ik nagedacht over normalisatie, maar ik denk zelf dat ik niet dieper kan gaan. Dus ik hoor graag van jullie!

Grz,
Do.

Neem je ook meteen de GIS-data mee? Is wel zo handig...

GIS data is inderdaad ook voorzien, ja.

Qua ontwerp maakt het niet zoveel uit welke versie je meepost, denk ik. De laatste versie lijkt mij dan de voorkeur te hebben. Wat betreft het gebruik van tabellen: hierbij moet je denken aan gegevens die bij elkaar horen. Dat lijkt simpel, maar is niet altijd eenduidig aan te geven. In beginsel werkt normaliseren op 5 niveau’s, al halen de meeste mensen (en databases) niveau 3 nooit. En dat is vaak ook niet nodig, normaliseren tot het derde niveau is doorgaans voldoende om een goede database te maken. Wil je dat proces doorlezen, dan zijn daar voldoende websites voor, en ik heb er in de Access cursus (in de Handleidingen sectie) de eerste hoofdstukken aan geweid.

Je moet hierbij denken aan gegevens die afhankelijk van elkaar zijn als het gaat om het eerste niveau. Dus personen in een personen tabel, gebouwen in een gebouwen tabel. Daarna ga je kijken welke gegevens afhankelijk zijn van een deel van de gegevens in een tabel. Dat is dan normaal 2. Maar goed, om dat allemaal nu uit te leggen gaat een beetje te ver, staat allemaal in de cursus tenslotte. .

Ik denk dat je met twee tabellen dus niet voldoende hebt genormaliseerd, want ik zou dat niet met twee tabellen kunnen maken.

Hallo, eerst en vooral sorry voor mijn lange radiostilte, maar we hadden een deadline voor een ander project (ongerelateerd aan Access).

Ik ben nu eindelijk weer in gang geschoten met de databank voor erfgoedrelicten. De keuzelijsten zijn ondertussen allemaal uit de tabellen gehaald (eigenlijk heb ik de tabellen opnieuw gemaakt, want gewoon aanpassen van het datatype in de originele tabel bleef vervelende meldingen geven). De keuzelijsten ga ik opnemen in de formulieren voor een gebruiksvriendelijke invoer. Had dit al getest na jullie eerdere feedback, en dat lukte.

Maar: voor sommige velden wil ik de gebruiker meerdere waarden laten selecteren. Met een keuzelijst in de tabel kon ik dit eenvoudig door 'allow multiple values' aan te vinken. Maar bij de keuzelijst in het formulier lijk ik deze optie niet te hebben.

Graag jullie tips!

PS: als ik hier beter een nieuwe vraag voor lanceer (wegens ander onderwerp of te lang geleden), laat het gerust weten!

Grz,
Do.

Erfgoedstudio zei:

Maar: voor sommige velden wil ik de gebruiker meerdere waarden laten selecteren. Met een keuzelijst in de tabel kon ik dit eenvoudig door 'allow multiple values' aan te vinken.

Klik om te vergroten...

Deze optie is alleen beschikbaar op tabelniveau. Dat komt omdat het niet echt een keuzelijst is, maar een (onzichtbare systeem)tabel die je vult. Dus dat zul je op tabelniveau moetn blijven maken. Daarna krijg je in je formulier uiteraard ook de juiste keuzelijst te zien. Probeer deze vorm van velden zoveel mogelijk te vermijden, want het is een (in mijn ogen) hopeloze aantasting van de integriteit/compatibliteit van je database. Hij is namelijk acuut niet meer genormaliseerd. De eerste regel is immers: in elk veld staat één waarde. En dat heb jij dan dus niet meer. En het onderhoud ervan in vervolgqueries is een rampenplan. Maar goed, als je ze wilt gebruiken: be my guest.

Dat begrijp ik. Heb gelezen dat Access dit weliswaar toont als meedere waarden voor 1 record, maar achter de schermen toch meerdere records heeft (als ik het goed begrijp).

Enfin, klonk inderdaad niet de meest 'propere' oplossing vanuit ontwerp standpunt bekeken. Maar welk alternatief is er als je in een formulier meerdere opties wil laten aankruisen door een gebruiker?

Aangezien onze DB gaat over eigenschappen van een gebouw, kom ik dat dus heel vaak tegen. Een dak kan bvb. tegelijk verschillende soorten bekledingen hebben. Als ik dat zou ontdubbelen, heb ik geen keuzelijstjes meer, maar allemaal aparte kolommen met bvb. ja/nee velden. Maar dat wordt heel onoverzichtelijk bij de invoer.

Dus als er betere alternatieven zijn, hoor ik het graag!

Er wordt, zoals ik al zei, een systeemtabel voor gebruikt. Dus je ziet een veld met één (kommagescheiden) waarde, maar het is een eigen tabel. Maar dat maakt het dus ook zo lastig, als je daar op wilt gaan filteren, of met een query wilt verwijderen. Je zult dan allerlei toevoeg queries moeten gebruiken. En in de export is het dus ook 3 keer niks, of je krijgt alsnog alles in één veld. Ik loop er liefst met een grote boog omheen.
Als het even kan, gebruik ik dus liever losse tabellen met een één-op-veel koppeling. Overzichtelijker en structureel een stuk makkelijker.

Je zegt dat jij de voorkeur geeft aan 'losse tabellen met een één-op-veel koppeling'. Maar dat heeft dan wellicht niet het beoogde resultaat: meerkeuzelijstje bij invoer? En dat is hier wel van belang. Dus ik vrees dat ik dan toch zal moeten kiezen voor de keuzelijst op tabelniveau.

Maar hier riskeer ik dan weer tegen mijn initieel probleem aan te lopen: je kan maar max 32 indexen hebben per tabel. En elke keuzelijst telt mee voor een index. In mijn huidige opzet heb ik per gebouw meer dan 32 meerkeuzelijsten nodig. Dus wellicht zal ik de data moeten opdelen over méér dan één tabel...

Ik ben nog niet erg ver met de DB zelf en er zit sowieso nog geen data in. Weet niet of je op basis hiervan kan oordelen of het ontwerp goed is? Maar mss kan ik de checklist eens doorsturen waar ik mij op baseer? Deze wordt gebruikt bij rondgang door de stad om de gebouwen te inventariseren. Zal wellicht een idee geven over de inhoud.

Grz,
Do.

Erfgoedstudio zei:

Maar dat heeft dan wellicht niet het beoogde resultaat: meerkeuzelijstje bij invoer? En dat is hier wel van belang.

Klik om te vergroten...

Dat is dan toch prima? Een aparte tabel kun je uitstekend gebruiken om meerdere keuzes op te slaan. Het is niet voor niets één-op-veel . Hoé je hem vult, kan dan op verschillende manieren worden uitgevoerd. Een (sub)formulier met een keuzelijst bijvoorbeeld, als je het simpel wilt houden, of een niet-gebonden subformulier met selectievakjes (dat dus een visuele representatie is van het 'veld met meerdere keuzes'), dan wel een gewone keuzelijst waarin je meerdere waarden kan selecteren. De laatste twee opties zijn wat ingewikkelder te maken, omdat je daarvoor een object (formulier, keuzelijst) nodig hebt met als basis de tabel waaruit je de gegevens moet kunnen selecteren. Eigenlijk zoals je nu dus ook hebt voor je veld met meerdere waarden. Maar zo'n object slaat dus nog niks op. Je zult dan ook een knop moeten hebben waarmee je de feitelijke records aanmaakt in de gekoppelde tabel.

Dus concreet krijg je dan: je opent een doorlopend formulier met de keuzes die gekozen mogen worden. Die haal je uit een tabel met daarin dus de VeldID, de veldnaam, en een Ja/Nee veld. Het IDveld laat je niet zien, dus je ziet alleen de naam en het selectieveldje. Net zoals je veld met meerdere waarden, maar dan mooier. Daar selecteer je de opties die je wilt hebben. Ben je klaar, dan klik je op <Toevoegen>. Nu wordt er een toevoegquery uitgevoerd, die de geselecteerde waarden in de koppeltabel zet.
Grote voordelen: de keuzelijsten zien er veel beter uit en je hebt veel meer invloed op het selectieproces. Wat een tabellijst niet kan: filteren op bepaalde waarden. En dat kan een formulier(query) dus wel. Stel dat je in de keuzetabel opties hebt die bedoeld zijn voor specifieke gebouwen. In de tabellijst kun je die niet filteren. Op een formulier wél. Dus het systeem is veel functioneler te maken.

Echt, ik heb die velden met meervoudige waarden zelden nodig. De enige reden dat ik ze gebruik is omdat ik moet weten hoe ze werken, om a) mensen zoals jij te kunnen helpen en b) diezelfde mensen er zo snel mogelijk van te overtuigen dat ze ze niet moeten gebruiken .

hmm, het komt er bij jou zo eenvoudig uit... Maar ik zie er mij zelf eigenlijk niet meer aan beginnen . Ik denk niet dat ik op mijn eentje op korte termijn voldoende ver zal geraken. We zouden in augustus graag beginnen met de invoer, dus er rest niet meer zoveel tijd voor mijn leerproces.

Kunnen jullie iemand aanraden die (tegen betaling) kan meehelpen?

Het hoeft ook allemaal niet zo moeilijk te zijn . Augustus is wel kort bij, en bij dat soort korte termijn planning maakt het ook nog uit of je op 1 augustus wilt beginnen (28 dagen) of op 31 augustus (58 dagen) . Als je wel een Functioneel Ontwerp hebt, of iets anders op papier, maar ik wel best wel naar (de structuur van ) de database kijken; dan zie ik gauw genoeg of het haalbaar is of niet.

Ik heb het ontwerp van het formulier op papier. Zal in principe gebruikt worden voor de rondgang langs de verschillende monumenten. Moet wel nog aangepast worden eens de structuur van de access form duidelijk is, zodat ze maximaal op mekaar afgestemd zijn (om het risico op fouten bij de invoer te verminderen). Kan ik je dit ook rechtstreeks mailen?

Qua timing mikken we op begin aug, maar als dat niet realistisch is, dan hoor ik het graag.

Ik heb ondertussen ook nog nagedacht over de 'nieuwe' mogelijkheden van Access voor dummies zoals ik, waarbij alles met wizards kan geregeld worden, en de manier waarop jullie als gevestigde waarden daar tegen aan kijken (niet alleen hier, maar ook op andere fora). Er wordt daar dikwijls heel laagdunkend over gedaan, en ik denk dat dit inderdaad soms met technologie te maken heeft (programmeren zal altijd robuuster zijn), maar mss ook omdat het zo laagdrempelig gemaakt wordt (ineens kan iedereen met access aan de slag). Anderzijds vraag ik me af hoe Microsoft zich deze strategie kan permitteren als het in het geheel niet zou werken. Ik heb voor onze DB het vermoeden dat het een heel eenvoudige is (gewoon invoer en opslag van inhoudelijke gegevens, geen complexe berekeningen,...). Ik ben eigenlijk wel benieuwd hoever ik zou komen met deze 'dummy-versie', maar het lijkt erop dat niemand zich eraan wil wagen om dit met mij te ontdekken

Erfgoedstudio zei:

Kan ik je dit ook rechtstreeks mailen?

Klik om te vergroten...

Je mag hem mailen maar octafish @ live.nl. Dan kijk ik er met alle plezier even naar.

Erfgoedstudio zei:

Er wordt daar dikwijls heel laagdunkend over gedaan, ... maar mss ook omdat het zo laagdrempelig gemaakt wordt (ineens kan iedereen met access aan de slag).

Klik om te vergroten...

Dáár zit dus het probleem: je kunt niet "zomaar" ineens een database maken omdat het programma dat faciliteert. Het bouwen van een database is een gecompliceerd proces, waar mensen doorgaans behoorlijk voor hebben doorgeleerd (ik dan toevallig nou weer niet, maar dat is een ander probleem ). Bij 'simpele' platte programma's als Word en Excel kan je prima zonder enige kennis van zaken documentjes maken, maar voor een database gaat dat gewoon niet op. Als ik jou een scherp (operatie)mes geef, en je vertel met welke kant je het beste kan snijden, dan zal je ongetwijfeld zonder enige hulp een biefstuk te lijf kunnen gaan. Maar daarmee heb je nog niet de skills voor een open hart operatie. Ook al kun je dat dus perfect doen met dat mes. En dat geldt dus ook voor software. Het feit dat je het programma hebt, wil niet zeggen dat je het correct kunt gebruiken. En op dat punt gaat Microsoft dus compleet de teil in, wat mij betreft. Hoe laagdrempelig ze het ook (kunnen) maken: als je geen verstand hebt van databases bouwen, zul je nooit een goede database kunnen maken.

Erfgoedstudio zei:

Ik ben eigenlijk wel benieuwd hoever ik zou komen met deze 'dummy-versie', maar het lijkt erop dat niemand zich eraan wil wagen om dit met mij te ontdekken

Klik om te vergroten...

Zie puntje 1 . Eerst zien, dan kan ik er een gefundeerde mening over geven.

Hi, om dit onderwerp af te sluiten even een update... Ik ben ondertussen goed gevorderd met mijn ontwerp. Heb wel gebruik gemaakt van meerkeuzelijsten in de tabel, gezien ik deze functionaliteit nodig had op niveau van het formulier en de mogelijke alternatieven té complex waren voor mij. Ik heb ondertussen werkende formulieren en subformulieren om alle tabellen te vullen.

Heb nu wel een paar andere vragen, maar zal deze via een nieuw bericht lanceren, gezien ze al ver verwijderd zijn van mijn initiële vraag.

@ octafish: ik had je nog dezelfde dag mijn file doorgestuurd, maar mogelijks is er iets mis gegaan? Heb in elk geval geen foutmelding gekregen.