network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 8 months |
| seen | Feb 26 at 11:01 | |
| stats | profile views | 2 |
|
Dec 3 |
comment |
Database Schema Usage Thanks, that's a very useful answer. I can at least now raise these arguments in our discussions |
|
Dec 3 |
comment |
Database Schema Usage No, I think it's unlikely that we will need to move any objects away from this server. So from what you've said it sounds like there is no "good" reason not to adopt their approach beyond my own personal preference. Thanks for your response |
|
Dec 3 |
comment |
Database Schema Usage Our motivation was to give us the option of controlling security this way further down the line, however this now seems less likely. Also, we felt that segregating our tables would be a good thing to do as there's nearly 100, and schemas seemed a neater way than purely using prefixes |
|
Sep 28 |
comment |
Should I create an Enum mapping to my database table I do like this suggestion, as in all probability there would be few enough systems requiring explicit reference in the code that we could have got away it, and all would have been fine. However, in the spirit of conforming to best practice we have decided to go with the Dictionary approach |
|
Sep 28 |
comment |
Should I create an Enum mapping to my database table Whilst Mike's point is certainly valid, in this situation most of the systems we add will not need to be explicitly referenced in the code as they will just need to be available in comboboxes etc. When system-specific functionality is required then we can refer to the system by name from the Dictionary, which will be infrequent enough to not cause a problem. We're in control of the data, so it is our responsibility to ensure we don't decide to rename 'Windows' to 'MS Win' (or whatever) and not update the code accordingly |
