May 3, 2016 at 11:27 pm
Comments posted to this topic are about the item What’s in a name?
May 4, 2016 at 1:09 am
Editorial - David.Poole (5/3/2016)
...Hopefully the new breed of CEO insisting that their companies should become data led will bring a sea change for us but I expect there to be a long hard slog ahead of us.
I think that, like many aspects of IT, the strong support and indeed guidance of some CEOs will provide benefit for their companies over their competitors.
Most worthwhile work is hard. But often harder than it should be.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 4, 2016 at 1:37 am
We've got a problem with entities having different names across different teams in the same business. To compound the issue, tables in the data warehouse have the same names as tables in the OLTP system but hold different data.
We have two types of 'task', one which is related to contacting a client and another that is related to jobs that are done when a client is visited. There is a 'contact' table on our CRM system that holds data about each client but the contact table in the data warehouse holds data about 'contact' with a client. These are known as tasks elsewhere. As you can imagine there is potential for confusion and frustrating calls when one side or another isn't explicit about what they are talking about.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
May 4, 2016 at 1:51 am
I prefer using two (or more) words where one is generic like Task, Contact or Profile. They are overloaded with meanings whereas a concatenation can assist clarity e.g. CallCentreTask, SalesContact and ClientProfile.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 4, 2016 at 2:15 am
@gary posted a comment on SOLID principles and I think it's well worth reading a summary of those principles.
Two principles that I take to heart and apply to data are that
1. An object should have a single responsibility
2. Identify when two things look like they could be the same class of object should actually be separate classes.
The example that springs to mind was where we collected data from feedback forms both from suppliers and from customers. It is so easy to fall into the trap of lumping both together. In this case the acid test was to look at situations when we would produce a single report capturing customer comments on our service to them and supplier interactions on unrelated matters.
May 4, 2016 at 5:54 am
Hey David, I totally follow SOLID principles but naming has to be careful when different entities could use the same name. Naming's first role is identification so clarity is a first class requirement.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 4, 2016 at 4:31 pm
Interesting article. I can't think of anything produced by a business unit (and to a lesser extent IT) that I've worked with that would pass for scientific precision in terms of classification like a botanist or a chemist might expect when describing their systems or processes. I never realized how dependent I was on implicit meaning in the code based on the nouns and verbs (for example) that are often built in to the code until I was handed a database written in Spanish for a Puerto Rican government health care system. That was a learning experience. The distillation of my experience has been to virtually ignore what someone calls something and classify it by it's behavior and attributes; then remove the duplicates from the model. I believe it pays long term dividends to have somebody maintaining an enterprise dictionary of shared business objects but it's really tough to find the right people or at least organize it in a way that isn't seen as an impediment by the rest of the business team.
May 5, 2016 at 2:31 am
Absolutely. A well maintained data dictionary is something that an organisation with mature data handling processes is likely to have.
Every trade has practices that craftsmen use and journeymen don't. The problem is that it takes time for the benefit of craftsmanship to become apparent.
May 5, 2016 at 5:54 am
David.Poole (5/5/2016)
...it takes time for the benefit of craftsmanship to become apparent.
Definitely.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply