James Button
jamesbutton at blueyonder.co.uk
Thu Sep 11 13:13:03 CDT 2014
My first consideration is the relationship you have with the users of the delivered system. If your contact with them is you provide it as specified by the 'management' than that is what you should do. Yes, you may discuss your concept of what is needed from the facility. And following that - maybe discuss what else the system may be required to do, and techniques that you, as an experienced developer believe are worth the extra effort - and consequent up-front cost with the targeted offset of future costs. That is basically a COST concept. Maybe you can suggest that some techniques be adopted as being minimal cost to avoid major constraints later - Y2K being a prime example - save 2 digits in a date - so the users don't have to enter the leading 19 all the time. AND - note the windows environment actually includes that concept - with a user specifiable range of years to be associated with the current century and the prior century. If you are working with the users then you have a good opening to prototype the facility and introduce what to you seem to be good design and input data handling and processing, while addressing the background maintenance and reporting needs. For instance - entering an animal - include their parents - with a search facility as a subsidiary option from the entry screen so they can search for the entries. But - what if the parent entries need to be entered - do that as a subsidiary process, or require them current entry to be abandoned in order to enter the parent entries. Then - Species - allow that to be selected from a list - with addition of new ones - or require a separate panel to 'add' Well you are going to need a panel for add, change, delete maintenance, and should you allow delete with cascade, or do it without cascade and leave orphan entries If a 'supervisor' has to do the delete, do they use a different panel, or the same panel with actions greyed out Strict normalisation - or just as needed for what they will be doing Stored procs - VBA on forms - DBMS with GUI included, built-in, or built-on audit and rebuild facilities It all comes down to money, and your relationship with the client as in is that interface at end- user, IT, or corporate management level, or maybe follow the documented & contracted requirements. I feel that those clients who willingly discuss matters of design with me at contract time get a far better result than those who tell me what they want and how it is to be done. And overall, I probably made more profit from the latter group than from those who were guided to systems that were logical and easy for them to understand and use. So - Horses for courses, providing the best ( to the clients view) facility you can for the money, and within their constraints JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don Sent: Thursday, September 11, 2014 6:27 PM To: Access Developers discussion and problem solving Subject: [AccessD] Design Considerations - Was: Table Structure Ideas The direction of this thread interests me because it resembles my own thought processes when evaluating different design considerations. I don't want to derail the conversation or muddy the water for the original poster, but I'd be interested in hearing the opinions of others on the implications of proposing a design approach that exceeds a client's stated requirements. In my experience, the client often has only a vague idea about how to structure data related to some task or problem, and usually has some narrow view about what a user interface should look like and how it should behave. Left to their own devices, clients would structure the data AFTER designing their preferred UI. They'll force the data structure to fit the UI, instead of ensuring a sound structure. Then, because the system was designed with a narrow vision of its function, entirely new systems may have to be developed (or existing ones extensively modified) to accommodate modest (and foreseeable) changes in the operating environment. (e.g., now we're testing samples of material x, using tests y and z.) This often leads to systems performing similar work in separate silos with no integration between them. How many times have we seen this when called in to design a solution? In the case of the problem presented here, it seems to me that there are three main entities that need to be modeled: Samples, Tests, and Test Results. In reality, there may be other entities involved with the application, such as the Client, the Job, the Sample Site, etc., but for now let's stick with Samples, Tests, and Results. Given this problem, I'd be inclined to construct a table for each of those entities, such that each sample may be related to one or more tests, and each test may be related to one or more results. A subsidiary table (or tables) could contain definitions for the various tests and constraining the types of results relevant to each test, and the types of tests relevant to each sample type. The advantage to this approach is that it provides a foundation for a solution to the current problem, while accommodating the (almost) inevitable future need to deal with new types of samples, tests, and results. Rather than adding new tables to accommodate ne! w tests and their results, we just add new records to the subsidiary tables that define the attributes and relationships of each. Test A may be materially different from Test B, in terms of how it's conducted and what is measured, but at bottom they're identical: activities that yield results that need to be recorded and evaluated. Now, I know that this sort of a design is a bit more complex, in terms of its development, implementation, and ongoing maintenance. It's not as easy to explain to the client, either. So I'd also be tempted to round off some corners and compromise in the directions so far proposed. So, I have a couple of questions: First, does the approach described above make sense, or am I totally off-base? I'm always impressed with the quality of the contributions from AccessD posters, and, not having seen a suggestion resembling mine, I wonder if I'm over-complicating things or missing something obvious that would argue against it. I often think in this way about a problem when designing a solution, and if there's a better way, I'm all ears. Second, and more interestingly, where does one draw the line between delivering exactly (or as near to it) what the client has asked for, and designing for a future that even the client may not anticipate? Is it ever appropriate to "out-think" the client and deliver a system that they didn't ask for and don't know they'll be needing? How do you all approach this question? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, September 10, 2014 11:44 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Table Structure Ideas You need a table for samples with a field that allows you to determine the order. Then you might use a table for Fibers Morphology and another for Polarized Light Microscopy, each with the fields needed for the information that applies. Each of those tables would be child tables to the main Sample table, which would contain any other information collected for a sample. The Sample PK would be a FK in each of the child tables. That would allow you to present the information in a variety of layouts without straining yourself. This assumes a one-to-one relationship between the tables but could allow for the addition of multiple results if you added a unique key to each child table as PK and allowed duplicates of the parent key. If they wanted to add different kinds of results, you would just add another table. Charlotte On Tue, Sep 9, 2014 at 11:11 PM, ACTEBS <actebs at actebs.com.au> wrote: > Hi Everyone, > > > > Got a complex form that we're turning into a DB and having difficulty > coming up with a good table structure to suit the form and the way the > data is collected and input. > > > > They want the Access DB to mirror the form. You can see the form here: > > > > http://download.actebs.com.au/FormDoc.jpg > > > > As you can see by the example image above the sample are marked as A, > B, C, and D, but sometimes they display it vertically and other > horizontally, which is confusing the hell out of me. Any idea on how > best to design the table structure so the data is easy to work with down the track? > > > > Any ideas most welcome. > > > > Thanks in advance. > > > > Vlado > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com