[MSSQL 2000] vanuit meerdere tabellen een FK op de ACL

[Verwijderd]

Ik ben de gelukkige die aan een content managment systeem mag werken waarvan het databaseontwerp brak is. Nu zijn we dat langzamerhand aan het omtoveren tot iets wat richting een genormaliseerd database gaat

Alleen kan dat niet zo snel aangezien de code die er boven op ligt daarvoor ook aangepast zal moeten worden en das behoorlijk veel werk.

Als eerste hebben we de huidige structuur van de db in kaart gebracht (voor zover dat kon, want er was geen documentatie en de db bevat geen metadata). Nu zijn we bezig om ook daadwerkelijk de relaties te leggen in de db tussen de tabellen en lopen we tegen een probleem aan waarvan we geen juiste oplossing kunnen vinden. Het heeft alles te maken met de tabel 'ACL' waarin alle rechten liggen op de onderdelen binnnen de database. Nu zit het zo dat ik een tabel 'Resources' heb waarin de soorten resources staan en ik daar rechten op kan geven middels de tabel 'ACL' (ik kan daar een gebruiker bijvoorbeeld volledige rechten geven om nieuwe pagina's aan te maken) daarnaast heb ik een tabel 'NavMenus' waarin alle knopjes zitten voor het menu waarop ik voor elk knopje ook weer rechten kan geven middels de tabel 'ACL'.

De sleutel ligt um in de guid (elke resource, elke menuknopje heeft een unieke guid) waarop in de tabel 'ACL' dus op aan guid en een userid rechten worden gegeven. Logischerwijs zou je dus denken dat je dus vanaf de guid van de tabel 'Resources' en 'NavMenus' een FK plaats naar de guid van de tabel 'ACL' zoals je hieronder ook kunt zien.



Als ik een tabel koppel met een FK aan ACL gaat dat goed, koppel ik er twee of meer aan en voeg ik bijvoorbeeld in Resources een nieuw record toe dan geeftie een error en zegtie datie ook wat verwacht in de tabel 'NavMenus'. Ook logisch, maar dat geeft wel een probleem. Nu kan ik bij de relatie zeggen datie die niet moet gebruiken bij updates en inserts, maar waar heb je dan nog een relatie voor nodig??? Vind ik persoonlijk dus geen oplossing. Ik weet dus dat het db model brak is (er horen nog een stuk of 60 tabellen bij het totale model), maar daar kan ik in eerste instantie geen wijzigingen in aanbrengen. Waar ik eigenlijk naar opzoek ben is een soort 'of FK', ik bedoel daarmee: of hij zit in tabel a of tabel b of tabel c... en dat kan dus volgens mij niet.

Vandaar de vraag: hoe is dit het beste op te lossen: geen relaties leggen maar dmv van een stored procedure (oid) de rechten laten regelen? of zijn er betere manieren te bedenken voor zo'n situatie...

[whoami]

Ik snap de bedoeling niet goed van de tabel navRelaties.
Geef je daarmee aan welke menu-items er onder een ander menu-item zitten? Zoja, waarom gebruik je dan geen self-join op navMenu ?

[Verwijderd]

Sorry, de tabel NavRelaties is opzich niet relevant voor het vraagstuk... het gaat puur om de rechten op resources binnen 'Resources' en menuitems binnen 'Navmenus' via de tabel ACL waar de FK vanuit beide tabellen richting de tabel 'ACL' elkaar in de wegzitten bij het toevoegen van records... (en dus bij het verwijderen waarschijnlijk dan ook...)

NavRelaties wordt idd gebruikt om een tree op te kunnen bouwen: en ja dat had met een self-join gekund maar daar ga ik nu niet op in

[EfBe]

Je moet je menu's dus ook in je resources table plaatsen. Je hebt 1 centrale resources table, DIE gebruik je om ACL's op te leggen en verder refereer je in bv NavMenu's met je resourceGuid naar Resources (dus resourceGuid is FK naar Resources.)

Overigens klopt er weinig van dit model. Je hebt Resources een 'ID' gegeven dat de PK is, maar er is ook nog een resourceGUID. Die IS uniek, is het niet zaak om resourceGUID als PK te kiezen? wordt je model ook een STUK duidelijker van.

[Verwijderd]

Als je mn openings post goed had gelezen, had je ook kunnen lezen dat bekend was dat het model meer dan brak is. Ik kan daarnaast dus ook niet zomaar het ID verwijderen uit de tabellen aangezien dat in de software gebruikt wordt, ik kan ook niet op een andere manier relaties leggen, ik wil alleen antwoord op de vraag: 'Kan ik op één of andere manier die meerdere FK richting ACL realiseren' en zo ja: 'hoe?'

[EfBe]

Verwijderd schreef op 02 maart 2004 @ 13:20:
Als je mn openings post goed had gelezen, had je ook kunnen lezen dat bekend was dat het model meer dan brak is. Ik kan daarnaast dus ook niet zomaar het ID verwijderen uit de tabellen aangezien dat in de software gebruikt wordt, ik kan ook niet op een andere manier relaties leggen, ik wil alleen antwoord op de vraag: 'Kan ik op één of andere manier die meerdere FK richting ACL realiseren' en zo ja: 'hoe?'

Ik heb dat gelezen, ik heb ook gelezen dat je het goed wilt maken. Ik geef aan hoe dat moet. Als dat dan niet kan is jouw probleem, stel dan de vraag niet wat je moet doen om het goed te maken.

Een model met FK relaties naar 2 of meerdere PK tables is fout en niet te gebruiken. Je moet dus eerst een wijziging doorvoeren in resources en daar alle resources in plaatsen, daarna de FK leggen van NavMenu naar resources en DAARNA met die ACL's gaan rommelen Jij wilt het andersom doen, dan krijg je problemen.

Overigens ondersteunt Sqlserver gewoon multi-FK's naar meerdere tables. Waarom is mij een raadsel, maar je kunt het gewoon gebruiken. Jij wilt echter iets gaan toepassen als oplossing voor een probleem dat een geheel andere oplossing nodig heeft. Ga NOOIT halfslachtige dingen 'maar even' toepassen omdat het nu 'even niet kan', want voor je het weet ben je 2 jaar verder en werk je nog steeds met je, sorry, brakke oplossing die 'toen even' is gekozen maar later nooit is aangepast.

Dus, eerst de volgorde van actie wat wijzigen, dan heb je minder problemen met het migreren van functionaliteit naar het nieuwe datamodel. (overigens wat is er gebeurt met n-tier development? Waarom heb je uberhaupt problemen met migreren?)

[ Voor 6% gewijzigd door EfBe op 02-03-2004 13:28 ]

[Verwijderd]

OK thnx voor de helder uitleg! Ga er zeker wat mee doen, dan moet de chef maar wat meer geduld hebben Anders blijf je idd tijden aazitten te hikken tegen een grote update...

n-tier hebben de ontwikkelaars van het cms nooit van gehoord (misschien dat ze daarom failliet gegaan zijn...) en het systeem draait nu al op zo'n 20 plaatsen met overal her en der een kleine aanpassing die door tijdsdruk niet overal zijn doorgevoerd (:shame:). Te lastig en redelijk complex om dat ff om te zetten met daarbij de grote wijzigingen in de db die nodig zijn...

[ Voor 10% gewijzigd door Verwijderd op 02-03-2004 14:04 ]