Hi,

 

I'm feeling the need to vent. I created a relatively simple database for managing our law firm's clients and projects, with a table for clients, and a separate table for projects that can be labelled as any of the several project types that we accept. We recently started accepting a new type of project, probates, which will likely be for individual clients who only have a single project with us (most of our clients have multiple projects with us). 

 

Anyway, the office manager decided to create a client record for "Probate" and then list every probate matter under that client number. That way we will be "saving numbers" instead of assigning a client number for a client who will likely only have a single project with us. I did not point out that it's highly unlikely we will run out of numbers, ever, in the course of a million years. 

 

I was really surprised at myself at how much this bothered me. I mean I had an adrenaline response, racing heart, all that stuff. 

 

Anyone else have any stories of users' "innovations" in the use of your databases? Any insights gained or lessons learned?

 

Thanks,

 

Tom

Anyway, the office manager decided to create a client record for "Probate" and then list every probate matter under that client number. That way we will be "saving numbers" instead of assigning a client number for a client who will likely only have a single project with us. I did not point out that it's highly unlikely we will run out of numbers, ever, in the course of a million years. 

 

You are correct to be concerned, Tom, for many reasons; I will mention two:

 

Never believe it's a one-time thing

Whenever a Client indicates it is a one-time thing ... they are usually wrong.  I and many other Developers who have been in the software design business for 15+ years will certainly confirm it as well ... never say never.  I admit to believing it sometimes and having it bite me EVERY TIME.  And changing the structure later is a nightmare (if not impossible).  

 

Impossible reporting and aggregating

So how do you count how many clients exist?  How would you generate a report by client?  You cannot.  Reports are based upon a single table unless you complicate your solution by using a temp table and twisting the logic to make it happen.

 

Throughout your solution's lifetime, you will have to say, "oh yes, that is right, it would work except for the Probates" and you will kick yourself repeatedly until you finally correct it.  It is fine for an Office Manger to decide what FUNCTIONALITY they need but it is not their job to decide how it is accomplished on the backend.

 

I encourage you to establish the proper boundaries or get in writing that it was against your advice to do so.

I believe that if you wrote the solution then you should be the "gatekeeper" and implement security measures that prevent any user from making design changes. Of course you must be prepared to walk away from the job if you run up against a brick wall with your boss/client/co-worker.

Hi LaRetta and Rick,

 

Thanks for your comments. Those are exactly my concerns. We will see how willing the office manager is to do things as the database was designed. 

 

Rick, the office manager hasn't made any design changes; she's just input data of the wrong sort to an existing field. I'm not sure how to prevent that, other than using validation to make sure the value for the client name field isn't "Probate" or another project type. Which actually isn't a bad idea I suppose. 

 

 

Thanks,

 

Tom

 

Tom

Tom,

 

Some times you have to put big buttons and hand hold people down the path when there is a fork in the road - buttons get them to unique areas that handle validate or process at the presentation layer however the underlying schema can be normalized that can save sanity.

 

 

 

Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. - Steve Jobs

 

one thing that could help is FMP 13 with fields that you can control visibility on and dynamic tab labels and other new design elements when the user creates a records the display response accordingly.

 

But yes the "innovation" of worker bees can be a challenge, making the 5' o'clock happy hour a much deserved respite.

I run into the same challenge with users. Sometimes its good to find a way to make them not want to be "innovative". Make the right way so irresistible that they don't even consider the alternative. That's why we make the big bucks. LOL

This is not a comment on the Tom's original issue, but sometimes developers can get "blinkered" into thinking one method of doing something is how it should be done. A user can come along and do things the "wrong" way, but one that turns out to a better solution.

Having said that, I created a database system that used individual records for each month and a portal to enter that month's related records. I showed the main person how to use it, how to create a record for a new month, etc. ... problem is that she never showed anyone else how to use it properly, and some people were entering everything into the portal for the same month (due to an over-sight on my part they were simply changing the month at the top when the database displayed the error saying they were entering a related record in the wrong monthly record). It didn't crate any problems for the database itself since each related record had it's proper date, but it meant the list in the portal was MUCH larger than it needed to be and wasting their data entry time scrolling through it.