Levels of Abstraction and Database Design (1 Viewer)
- Thread starter Banana
- Start date
KenHigg
Registered User
- Local time
- Today, 02:44
- Joined
- Jun 9, 2004
- Messages
- 13,327
I hate to step in to ya'lls discussion as a johnny come lately, but...
Up to this point the dialog seems to be centered around a table/form model. Would a model with intermediate 'configuration' tables help solve some of the issues you're having?
Ken
Up to this point the dialog seems to be centered around a table/form model. Would a model with intermediate 'configuration' tables help solve some of the issues you're having?
Ken
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
Regarding persons, roles, attributes, contracts...
The question has to be; Who carries the baggage?
Let's look at it descriptively.
In a multi-contractor situation, who provides the employees? Contractors. Who specifies the roles? Probably the customer NAMES the roles but the contractors provide them. Who specifies the attributes? Again, the customer will probably specify what is needed but it is the contractors who have a company policy handbook. So the question is, where are the junctions in the attributes?
Well, hell, son, that depends on the situation. Which is why database design isn't for wimps. It can change from one case to another. However...
There comes to mind a couple of possible scenarios.
The companies each define roles and the attributes come from the company. Then you join the employee to the role s/he fills. The attributes belong to the roles, which depend on the companies. So it is possible for two companies to supply people for the same rule but have different attributes for the role. In this case, the attribute must depend on company and role. But the employee just links to the appropriate role. If you take the view that two roles with different attributes are different roles (despite similarities) then the employee just has a two-way junction to the role - but the "applicable attribute"s join the contract and role to the list of "possible attributes." So the latter is a three-way join.
It is also possible to say that the nature of the employee relationship to their employers is not fixed because they have individual contracts as opposed to being a simple employee. (I.e. the company is a broker, not a direct employer.) In this case, the actual attributes depend on the EMPLOYEE, Role and list of possible attributes.
Then there is the mixed bag, a little bit of each. This is the one that is a headache, but you can still do this. Here you have a list of possible attributes and a bunch of possible roles. The junction tables merely identify which attributes belong with which roles, but here, you might have to identify TWO sub-sets of roles - those defined by a company and those defined by a brokered contract. Then form the UNION query of the roles and their attributes to complete the definition.
If I had the latter case, I think I'd try a new line of work. But I've actually seen it happen with Dept. of Defense. {shudder}.
So the question is, do you need the junction tables to include person, company, role, and attribute? This is why I said it depends. You can argue that you really only need Employee, Role, and Attribute - where the roles associated with each employee are EITHER employment-based or brokered contract-based. So if the roles in question are different based on the attributes, you don't need the company in the attributes listing. (You DO need it in the Roles listing.)
Then again, it is not a pretty model. And ugly models make for ugly databases.
The question has to be; Who carries the baggage?
Let's look at it descriptively.
In a multi-contractor situation, who provides the employees? Contractors. Who specifies the roles? Probably the customer NAMES the roles but the contractors provide them. Who specifies the attributes? Again, the customer will probably specify what is needed but it is the contractors who have a company policy handbook. So the question is, where are the junctions in the attributes?
Well, hell, son, that depends on the situation. Which is why database design isn't for wimps. It can change from one case to another. However...
There comes to mind a couple of possible scenarios.
The companies each define roles and the attributes come from the company. Then you join the employee to the role s/he fills. The attributes belong to the roles, which depend on the companies. So it is possible for two companies to supply people for the same rule but have different attributes for the role. In this case, the attribute must depend on company and role. But the employee just links to the appropriate role. If you take the view that two roles with different attributes are different roles (despite similarities) then the employee just has a two-way junction to the role - but the "applicable attribute"s join the contract and role to the list of "possible attributes." So the latter is a three-way join.
It is also possible to say that the nature of the employee relationship to their employers is not fixed because they have individual contracts as opposed to being a simple employee. (I.e. the company is a broker, not a direct employer.) In this case, the actual attributes depend on the EMPLOYEE, Role and list of possible attributes.
Then there is the mixed bag, a little bit of each. This is the one that is a headache, but you can still do this. Here you have a list of possible attributes and a bunch of possible roles. The junction tables merely identify which attributes belong with which roles, but here, you might have to identify TWO sub-sets of roles - those defined by a company and those defined by a brokered contract. Then form the UNION query of the roles and their attributes to complete the definition.
If I had the latter case, I think I'd try a new line of work. But I've actually seen it happen with Dept. of Defense. {shudder}.
So the question is, do you need the junction tables to include person, company, role, and attribute? This is why I said it depends. You can argue that you really only need Employee, Role, and Attribute - where the roles associated with each employee are EITHER employment-based or brokered contract-based. So if the roles in question are different based on the attributes, you don't need the company in the attributes listing. (You DO need it in the Roles listing.)
Then again, it is not a pretty model. And ugly models make for ugly databases.
The_Doc_Man, thanks for cementing the question of how one would determine the relationship.
Regarding models, no, it's not pretty, and I can thank my government bureaucracy for that. However, for some reasons, I had the impressions that snowflake and star models I referred to earlier was a standard feature in a database class, and thought that databases should at least try to approximate such models (or maybe there's more "ideal" models out that I've yet to hear of). Were you implying that the ideal model represents exceptions rather than the rule in realm of database designs?
But maybe KenHigg can intrigue me in the idea of having "configuration tables" to govern how everything will mosh with everything else.
Also, now that we know that it's okay to trace a relationship back to original tables, provided that the whole setup is correct. I've now lost my customary definition of circular reference as the tracing idea may not be always true. When does such set of relationship, especially for more than two tables, becomes circular and therefore unsolvable?
Regarding models, no, it's not pretty, and I can thank my government bureaucracy for that. However, for some reasons, I had the impressions that snowflake and star models I referred to earlier was a standard feature in a database class, and thought that databases should at least try to approximate such models (or maybe there's more "ideal" models out that I've yet to hear of). Were you implying that the ideal model represents exceptions rather than the rule in realm of database designs?
But maybe KenHigg can intrigue me in the idea of having "configuration tables" to govern how everything will mosh with everything else.
Also, now that we know that it's okay to trace a relationship back to original tables, provided that the whole setup is correct. I've now lost my customary definition of circular reference as the tracing idea may not be always true. When does such set of relationship, especially for more than two tables, becomes circular and therefore unsolvable?
KenHigg
Registered User
- Local time
- Today, 02:44
- Joined
- Jun 9, 2004
- Messages
- 13,327
Sorry for the delay...
In the simplest form that I can think of would be as follows:
1. You have one table that has generic text fields. This table contains the actual user data.
2. Then in another table you have entries that contain say, the field names for the fields in table 1.
3. So in table 1 each record would have a field that tells the system which record in table 2 it should use for the field names.
4. etc, etc
Object oriented languages like c use classes, etc to do this and I think you can do it Access VBA but I haven't tried it...
Hope I haven't muddled up the discussion you guys were having-
ken
In the simplest form that I can think of would be as follows:
1. You have one table that has generic text fields. This table contains the actual user data.
2. Then in another table you have entries that contain say, the field names for the fields in table 1.
3. So in table 1 each record would have a field that tells the system which record in table 2 it should use for the field names.
4. etc, etc
Object oriented languages like c use classes, etc to do this and I think you can do it Access VBA but I haven't tried it...
Hope I haven't muddled up the discussion you guys were having-
ken
Would that be similar to a table of Attributes to which different Roles could be joined together via a junction table? The form would then use a query to identify what attributes a role has, and display the attributes on form for the user to answers?
Or is it something a little different?
I considered the usage of spot exceptions and VBA to identify which records couldn't be processed further due to such exceptions and the "poor mechanic is one who doesn't uses all tools in toolbox".
Seems to me the biggest problem with using VBA to catch exceptions is that if exception is good for a certain set of records, we'd need to code another block to catch a slightly different exception. Therefore, would it not be logical to do this in two ways:
Quick'n'Dirty method:
Create a custom button for menubar. Let's call it Exception. User try to enter in the record, but is unable to do because it has information that doesn't really fits the format. Therefore, the user fills in all what can be filled then clicks in the button.
The button executes a code that copies the form's name, recordsource, and all controls with their entered value, and displays a popup input box with memo field for user to describe why the record couldn't be completed as normal. All of this information is then saved to a table; "tblExceptions" which at one point, the DBA can look over the information and decide what to do:
1) berate the user for take the easy way.
2) identify the pattern of exceptions and update the design accordingly.
3) Adds the record to expected table while overriding the rules somehow (is that even possible?)
4) Do nothing.
The method would work well as long as the system doesn't consume too much of DBA's time. In a way, it's self-documenting and can help DBA highlight the problem area in the design and improve upon it. But for a database with 1,000 users, or something like that, this isn't a feasible system. Which brings us to method #2.
Hard'n'gritty method:
Create a table of exceptions with the necessary fields. It also must include a field that indicate how to response. Whenever there is a spot exception, create a new record in the table with the response (ignore it, enter a state flag, or force user to choose something). Therefore, it's a simple matter of insert in a form's AfterUpdate event to call a public function that will check if the record meets the exception's criteria given in the exception table, and return the appropriate response for VBA to process. This way, VBA has no specifics about handling an exception and therefore can handle any exceptions one think of. Of course, I'm bit stumped on *exactly* what fields the table of Exception would need to have.
But the point here is, there shouldn't be a reason to use VBA to catch something when it can be stored in tables, like attributes and also exceptions....
Or is it something a little different?
~~~~~~~
I considered the usage of spot exceptions and VBA to identify which records couldn't be processed further due to such exceptions and the "poor mechanic is one who doesn't uses all tools in toolbox".
Seems to me the biggest problem with using VBA to catch exceptions is that if exception is good for a certain set of records, we'd need to code another block to catch a slightly different exception. Therefore, would it not be logical to do this in two ways:
Quick'n'Dirty method:
Create a custom button for menubar. Let's call it Exception. User try to enter in the record, but is unable to do because it has information that doesn't really fits the format. Therefore, the user fills in all what can be filled then clicks in the button.
The button executes a code that copies the form's name, recordsource, and all controls with their entered value, and displays a popup input box with memo field for user to describe why the record couldn't be completed as normal. All of this information is then saved to a table; "tblExceptions" which at one point, the DBA can look over the information and decide what to do:
1) berate the user for take the easy way.
2) identify the pattern of exceptions and update the design accordingly.
3) Adds the record to expected table while overriding the rules somehow (is that even possible?)
4) Do nothing.
The method would work well as long as the system doesn't consume too much of DBA's time. In a way, it's self-documenting and can help DBA highlight the problem area in the design and improve upon it. But for a database with 1,000 users, or something like that, this isn't a feasible system. Which brings us to method #2.
Hard'n'gritty method:
Create a table of exceptions with the necessary fields. It also must include a field that indicate how to response. Whenever there is a spot exception, create a new record in the table with the response (ignore it, enter a state flag, or force user to choose something). Therefore, it's a simple matter of insert in a form's AfterUpdate event to call a public function that will check if the record meets the exception's criteria given in the exception table, and return the appropriate response for VBA to process. This way, VBA has no specifics about handling an exception and therefore can handle any exceptions one think of. Of course, I'm bit stumped on *exactly* what fields the table of Exception would need to have.
But the point here is, there shouldn't be a reason to use VBA to catch something when it can be stored in tables, like attributes and also exceptions....
KenHigg
Registered User
- Local time
- Today, 02:44
- Joined
- Jun 9, 2004
- Messages
- 13,327
fyi: In a perfect world (you only read about these ), you put as few rules as possible in the table, as few as possible in the front end (forms & code behind forms) and put it all in an intermediate location. In Access this would be custom code modules. All transactions like add & update records are called from these. This way you have the most flexiblity in designing & updating the UI. Only one spot in the app to add, update & delete records which can be called from any form (or UI for that matter), etc... Of course this seems a bit over kill for most of the Access apps that I've built...
ken
), you put as few rules as possible in the table, as few as possible in the front end (forms & code behind forms) and put it all in an intermediate location. In Access this would be custom code modules. All transactions like add & update records are called from these. This way you have the most flexiblity in designing & updating the UI. Only one spot in the app to add, update & delete records which can be called from any form (or UI for that matter), etc... Of course this seems a bit over kill for most of the Access apps that I've built...ken
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
Having now looked at what Ken is suggesting, I doubt it will work that way for only one nit-picky reason. Access, as we have mentioned in passing, is not fully object-oriented. The Collections interface hides a multitude of sins that we simply cannot get to without violating the "reverse engineering" clause in the End User License Agreement.
It WOULD be possible to use this level of indirection in a program and even VBA has a slight chance to do this. BUT... the other interfaces would never do this as they use the Collections directly without our ability to intercept what they do. The problem is that Access doesn't really have a "redirection" data type - in essence, a pointer to another field - because its level of abstraction is not that general. In any OTHER language environment where pointers are supported fully, you could do this.
The pointer data type exists in Access but is hidden by syntax. When you declare a variable to be DAO.Database and then do an OpenDatabase method on a named database, that is really a pointer to the (dynamic) structure that defines an open database in your workspace. When you declare a variable of type Control to pass into some generic control-properties manipulator, that is a pointer to a data structure that abstracts Control properies. We could name other cases but you get the idea. If you define it with a SET verb then it is probably a pointer.
VBA implements these data types. Jet does not. And therein lies the problem with using Ken's suggestion.
It WOULD be possible to use this level of indirection in a program and even VBA has a slight chance to do this. BUT... the other interfaces would never do this as they use the Collections directly without our ability to intercept what they do. The problem is that Access doesn't really have a "redirection" data type - in essence, a pointer to another field - because its level of abstraction is not that general. In any OTHER language environment where pointers are supported fully, you could do this.
The pointer data type exists in Access but is hidden by syntax. When you declare a variable to be DAO.Database and then do an OpenDatabase method on a named database, that is really a pointer to the (dynamic) structure that defines an open database in your workspace. When you declare a variable of type Control to pass into some generic control-properties manipulator, that is a pointer to a data structure that abstracts Control properies. We could name other cases but you get the idea. If you define it with a SET verb then it is probably a pointer.
VBA implements these data types. Jet does not. And therein lies the problem with using Ken's suggestion.
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
I would think Ken's suggestion falls in the "something different" category.
Absolutely true, and it is why in my prior comments I mentioned that there was an issue with just how many of these you had. There is a threshold (probably a personal tolerance level) after which you say, "OH, PSHAW!" I'll have to figure out how to encode this in a table. (If you really DO say that, please don't be surprised at any strange looks you get...)
Also, we have to consider a semantic fine point.
Ken suggested that we should avoid placing RULES in tables. He's right. But it's also a generalization that is tricky to accomplish as he describes it.
In fact, Access cannot store a rule in a table (other than you could state the rule in English in a text field, of course). Because RULES in most DB environments translate to "data triggers." Validations in Access are limited to simple statements like ">0" or "Len(field) <= 5" . A "real" trigger would say "valid if X is NOT IN table YZ and X IN table WV and ...." - AND might include what you do if the validation is violated.
Access doesn't have this kind of data-oriented trigger. So when you have RULES in the formal sense, you MUST put them in VBA code, called from behind a form, and assure that nobody can get underneath the form to muck about in the tables directly or through updateable queries.
Ken's other comment in that same post is a strategic layout suggestion that is more about style than any requirement, but I don't disagree with his choice.
If I read it right, he is suggesting that all rules go into General Modules (not Class Modules) and that the forms that do your real work therefore can call any RULE implementor as needed from ANY form. To which I say, "Makes perfect sense to me."
As to my comment about "... poor programmer who won't use all the tools in his toolkit..." - don't take that as a call for overthinking a problem. If all you need are some simple queries and a macro to run them in a given sequence, one can legitimately argue that you should not go beyond that point. Or maybe, once the macro is right, convert it to a single VBA sequence, which is something you can do with a macro, and after that, run it via a call from a VBA action routine or a macro that includes only one line, RunCode.
The point being, overkill is overkill. If you are hammering in carpet tacks, there is no need to use the 16-pound maul to do so. A tack hammer works fine, thank you very much. BUT it is a poor general contractor who wants to break up large amounts of concrete without using a jackhammer.
Or... if you are cutting down one tree, use a hatchet or a hand saw. If you are cutting down a forest, use chainsaws or a tree-cutting machine. Which is, of course, an alternate solution to the problem of not seeing the forest for the trees...
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
Ken, thanks for asking.
New Orleans is only up to about 60% of its previous population, and most of that is in the 'burbs to the north, south, and west. Woefully large parts of the city and some of the 'burbs to the east are still devastated and only partly occupied. Heck, city services such as lights, water, gas, and sewerage are still spotty in N'Awlins East (an unofficial but geographically accurate designation). The ground got so soaked that any sub-surface piping was pretty much destroyed by ground swell.
You know that old adage about the only folks who make money in a lawsuit are the lawyers? N'Alwins is a positive HAVEN for lawsuit-minded lawyers. FEMA is dragging its feet on settlements. The Army Corps of Engineers has more or less accepted blame for what happened (but not 100% of it). Some of the government grants are approaching a deadline for filing and the lawyers are predicting a huge tide of insurance lawsuits over inadequate and improperly handled claims.
I remember seeing estimates that the city could not possibly recover in less than 5 years and might take up to 25 years. August 29th will be two years. No, we (the general population) have a long way to go.
As to me personally, we are back in the house after 2 feet of water trashed the downstairs. All furniture, applicances, (no-longer) dry wall, wiring, flooring, and items stored loose on shelves were messed up. Took us over 13 months to get the house liveable. We still have expenses to cover. But it is now comfortable for us. My stepdaughter, on the other hand, is still putting in a LOT of sweat equity on her house in the Lakeview section of town.
The tourist areas are up. Many of the restaurants are up. Most of the hotels are up (some under new management). The musicians are mostly back. But there are sections where the poorer people have no practical way to "come home." No home, no belongins, and neither a government settlement nor a private insurance settlement.
My biggest disappointment is the insurance companies, whose attitude is not in line with their TV and magazine ads. Don't get me started on that one, the soap box would have time to bio-degrade before I would finish my rant on THAT subject.
New Orleans is only up to about 60% of its previous population, and most of that is in the 'burbs to the north, south, and west. Woefully large parts of the city and some of the 'burbs to the east are still devastated and only partly occupied. Heck, city services such as lights, water, gas, and sewerage are still spotty in N'Awlins East (an unofficial but geographically accurate designation). The ground got so soaked that any sub-surface piping was pretty much destroyed by ground swell.
You know that old adage about the only folks who make money in a lawsuit are the lawyers? N'Alwins is a positive HAVEN for lawsuit-minded lawyers. FEMA is dragging its feet on settlements. The Army Corps of Engineers has more or less accepted blame for what happened (but not 100% of it). Some of the government grants are approaching a deadline for filing and the lawyers are predicting a huge tide of insurance lawsuits over inadequate and improperly handled claims.
I remember seeing estimates that the city could not possibly recover in less than 5 years and might take up to 25 years. August 29th will be two years. No, we (the general population) have a long way to go.
As to me personally, we are back in the house after 2 feet of water trashed the downstairs. All furniture, applicances, (no-longer) dry wall, wiring, flooring, and items stored loose on shelves were messed up. Took us over 13 months to get the house liveable. We still have expenses to cover. But it is now comfortable for us. My stepdaughter, on the other hand, is still putting in a LOT of sweat equity on her house in the Lakeview section of town.
The tourist areas are up. Many of the restaurants are up. Most of the hotels are up (some under new management). The musicians are mostly back. But there are sections where the poorer people have no practical way to "come home." No home, no belongins, and neither a government settlement nor a private insurance settlement.
My biggest disappointment is the insurance companies, whose attitude is not in line with their TV and magazine ads. Don't get me started on that one, the soap box would have time to bio-degrade before I would finish my rant on THAT subject.
Precisely why I started this thread in first place. When the idea of storing attributes as records instead of fields was proposed in that other thread, this totally threw me off the balance. For some reasons, I've come to think about such level of abstraction being too high and thus inappropriate. I've already mentioned how I got that idea from seeing other designs which seems to have some degree of specifics; something about a class, but never a class of classes. Or to put it in zoology terms, I've not seen design abstract above the species level to phyla, family or order level, let alone kingdom level.
But when I saw that storing attributes as record was ultimately normalized compared to that three-legged tables, I had to seriously re-consider whether I can expect Access to handle high level of abstraction I may want (but then again, maybe it's ME who's overcomplicating things!).
Now I'm starting to understand why some people describe triggers as a feature of other RDBMS programs. When I first head of them, I was like, "So what? Doesn't VBA basically does this?" But since the triggers can be driven by events (e.g. insert record) which would allow me to catch such records and test if there exists an appropriate entry in parent tables before the junction record is create), I can now simplify the form design and base it on one or two table, and let the engine do all the rule-enforcing things.
But Ken has suggested that this be done with modules, which could duplicate the triggers' functions; I would then insert a call procerdure in appropriate afterupdate events for a given form to check the data integrity not otherwise readily apparent to the database engine, especially where we are concerned with three ways junction tables which which depends on two parent tables that also has relationship to each other (e.g. person/roles, roles/attributes and person/role/attributes).
I still need to think the specifics out, but if the reasoning is correct, then this will abstract away the classes that are related in non hierarchical fashion, *and* be able to enforce data integrity without falling into the trap of creating an "exception catcher" function that is good just for one exception (and God knows, the government bureacracy will definitely throw me one more friggin' exception that will throw the database out of whack if I were to be fairly specific!).
Pretty bad when the lawyers, etc are as big an issue as the storm itself...
Hmmm... Time to call for a open season on lawyers? We could all go on a hunting trip, shoot one ourselves, then tie it to our Volkswagen bug's hood and have ourselves beers as we careens down the road to roast the lawyer.
But seriously, I'm glad to know that The_Doc_Man is back under the roof, and seems to be making progress in tidying up the house. One bright side to the recovery is this: You definitely do NOT have to deal with byzantine buildings, codes, or put up with old wires and utilities connection. You're going to get modernized much more faster than other cities who has to gradually update their system. Provided that the lawyers doesn't get in the way...
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
First, Ken, you weren't butting in. Thanks for the suggestion. It just happened to not be applicable in the case in point, but it works in other cases.
Second, the only reason I'm not behind bars right this second is because when we complained loudly to our insurance company, they replaced the first adjuster with someone else who actually KNEW something. The first guy as much as admitted to us that the ink on his adjuster's certificate was still wet. (As well as the area behind his ears, apparently.) In the Non-Access Issues forum I sometimes come off as a little bit trigger-happy, but the truth is that I'm not. This guy seriously tempted me to change that. My stepson also actually threatened the same guy. I gather he was such a loser that he was moved to another parish because the complaints really mounted, to the point of immediate threat of a lawsuit for using incompetent representatives.
As bad as Louisiana had it, some of the people in Mississippi have had to file class-action suits for outright fraudulent claim resolution. For example, artificially altering the engineering reports to re-balance damages so that more of the claim went to the flood policy. See, the flood policy was in part federally subsidized so the claim is picked up in part by FEMA. So the big insurance companies line their pockets at the expense of taxpayers. Some parts of Waveland and Biloxi had that problem. We had friends in Waveland whose house was leveled down to concrete slab - and they weren't on the coast. This was storm surge that did the damage.
Trust me, if somebody died and that made me king, some insurance executives would be out of a job with their pensions and stock holdings confiscated for redistribution to the persons their policies have harmed. I don't know if I would hold any executions, but there would be public flogging for sure.
Second, the only reason I'm not behind bars right this second is because when we complained loudly to our insurance company, they replaced the first adjuster with someone else who actually KNEW something. The first guy as much as admitted to us that the ink on his adjuster's certificate was still wet. (As well as the area behind his ears, apparently.) In the Non-Access Issues forum I sometimes come off as a little bit trigger-happy, but the truth is that I'm not. This guy seriously tempted me to change that. My stepson also actually threatened the same guy. I gather he was such a loser that he was moved to another parish because the complaints really mounted, to the point of immediate threat of a lawsuit for using incompetent representatives.
As bad as Louisiana had it, some of the people in Mississippi have had to file class-action suits for outright fraudulent claim resolution. For example, artificially altering the engineering reports to re-balance damages so that more of the claim went to the flood policy. See, the flood policy was in part federally subsidized so the claim is picked up in part by FEMA. So the big insurance companies line their pockets at the expense of taxpayers. Some parts of Waveland and Biloxi had that problem. We had friends in Waveland whose house was leveled down to concrete slab - and they weren't on the coast. This was storm surge that did the damage.
Trust me, if somebody died and that made me king, some insurance executives would be out of a job with their pensions and stock holdings confiscated for redistribution to the persons their policies have harmed. I don't know if I would hold any executions, but there would be public flogging for sure.
Wait, wait, why do you say that? I thought it was a feasible solution for enforcing rules?
An aside: I just consulted one of my reference books to see what they have to say about class modules. It devoted at most, two paragraphs. Two paragraphs.
No wonder classes modules is seriously underrated....
No wonder classes modules is seriously underrated....
- Local time
- Today, 01:44
- Joined
- Feb 28, 2001
- Messages
- 27,408
Apples and oranges.
Ken's design talked about abstracting the table so much that he had generic fields and then a second table (in effect) that pointed to selected members of the first table as a sort of dynamic mapping. For the reasons I stated, Access doesn't allow such indirection. That is the type of abstraction Ken was describing - if I read that right.
RULES are not RELATIONSHIPS. Ken's suggestion about where to put rules (in the sense of triggers) is right on the mark.
