in reply to User access DB design
A big consideration is whether you'll be maintaining the privileges in this database (updating, deleting, etc.) or only reading them. If you're only reading them, it makes sense to make it fast to retrieve and easy to update en masse when you get a refresh from the other department. On the other hand, if you'll be maintaing the values in your own database, then you want to make it fast and easy to update a single user's priviledges.
It's hard to tell without knowing more about the particular data involved, but if it's essentially read-only with bulk refresh, a big bucket-o-bits may be the way to go. If you're maintaining the data yourself, then a normalized data model will make coding much simpler.
Of course, these are generalizations; a normalized data base retrieval may be faster even in the first case, depending on the amount of data, cachability, the programmers' skill, and so on. If you have the time and the resources, the only way to tell for sure is to build and measure. Just from a gut feel, though, I agree with you: let the database do the lookup work.
HTH
|
|---|