Inline comments below....
"Jack Leach" <dymondjack at hot mail dot com> wrote in message
describes the contents of a table that it would have to be renamed.
Perhaps I can explain the scenario a bit more so that you may understand.
As nice as it would be, this root of this matter that we are discussing
actually has very little to do with the name of objects, but instead a
matter
of business survival. Not a matter of application design, but of business
survival... a far far more important concept than mere object names in an
Luke Chung of FMS Inc writes and article explaining these concepts in
detail, and what we can do to work with them as developers. I will post
the
link to this article, and quote some statements out of it for the purpose
of
this discussion.
Quotes from the article:
"As application developers, we've always been constrained by resources,
time, and budgets, so that's not new. What's new is the heightened focus
on
this, combined with the rapidly changing environment."
"A 50% solution this month may be worth more
than a 100% solution in six months"
"The 100% solution may be irrelevant when it's done"
Regardless of the state of the deliverable when placed into production, it
is in the organization's best interest to have a very solid conceptual
foundation for the solution, even if there are portions of the concept that
are not implemented when the application initially goes live or never
implemented over the course of its lifetime. Yes, conceptualizing the
solution will take time, but show me an example of a business decision, any
decision, where careful thought and analysis *isn't* a part of the decision
making process. Furthermore, skimping on the conceptualization can actually
cost you more in the long run. When you know from day one the direction that
the solution is going to take, or may take, you eliminate the need to go
back and rework things after it goes live. You move to a point where you can
focus on introducing new functionality. If you knew that spending two or
three days conceptualizing the design would save you a ten days later on,
wouldn't you jump at the chance. Yes, it adds more time to the initial
delivery date but in the long haul you end up saving time as the fully
conceptualized design, if well thought out, will allow you to implement
changes faster. When a developer buys up 1,000 acres for a master-planned
community, there's always a high-level design that dictates the development
of the land, even if it's in stages over years. The plan shows the final
design of the community, the placement of apartments, condos, homes,
business districts and roads. The developer just doesn't start building
projects without having an idea of the final result. The Orlando
International Airport was master-planned in the mid-1970's, but actually
built over a 20 year span. Even today the original plan has not been 100%
realized, but its very, very close. If OIA hadn't been master-planned, you'd
see a hodge podge design in its layout, like many other older airports that
have been expanded over the years. Take a look at the layout for McCarran.
Conceptualizing your application does not have to require months and years.
Depending on the scope, it could be a day or two, maybe over the span of
week to allow things to gel, but in the end you'll ultimately save time from
*not* having to go back and change things. The truest test of the validity
of any design ultimately in its flexibility to expand with a minimum of
fundamental changes. Conceptualize correctly and the additional of new
functionality to support changing business requirements will much, much
easier to accomplish.
"Even "perfectly" designed and developed applications may become useless
for
reasons beyond your control. The changing economy, new regulations,
changing
customers, products, or services, etc. can all make a "great" application
irrelevant. Being able to create something quickly, get it in use, and
adjust
it "on the fly" is a powerful skill and philosophy. Especially in these
uncertain times"
"Applications are like living beings. The survivors evolve, the bad ones
go
Myself, I am not an application developer. I am a business manager, and
application development is merely one of the great many tasks that I take
on
to ensure the stability of my business. In my particular industry,
regulations and requirements constantly take on a new face, and over the
past
three years this obstacle has grown exponentially.
Regulations and industry requirements should never be the basis for an
application's design. Yes, that's exactly what I said. Rather, the
application should be based on the business process that it is intended to
support. Processing an order is processing an order. Designing a custom part
for a machine is designing a custom part for a machine. The *process* does
not change. The tools, materials, regulations and standards may. In support
of those things, you design the application to be *compliant*. If you're an
architectural firm designing for both hotels and residences, you design the
application so that the *project* has a classification (hotel/residence) and
that each part/material can be flagged appropriately for use in a hotel,
residence or both. If you're dealing with requirements, you design the
database so that requirements are treated as much as possible as *data*.
Does that mean that you won't have to code in order to enforce
business-rules (requirements), NO? Does that mean that doing so will make it
easier than coding the requirements, NO? It does mean that you will have to
think harder and probably coding more up-front, AND it means that you won't
have to do as much of either down the road.
In the end, it's a trade off that's an inverse relationship. Go for a
shorter time to delivery doing minimal conceptualization now, but spend more
time adapting later or go with a longer time to delivery but spend lesser
time adapting later on. Do you want it *now* or do you want to be able to
quickly adapt in the future? Keep in mind that a 'longer time to delivery'
is not necessarily *years* or *months*. You're trading off the benefit of
having it today at the cost of flexibility for the benefit of flexibility
and getting it next week.
Again, you have to think of the big picture and like any business decision
give it thought and consider the consequences and trade-offs.
My job is not to design a master application that will withstand the tests
of all time, even if nothing were to change. Rather, my job is to provide
functionality under a pressured timeframe that coincides with the demands
of
the industry that I am involved in.
So your organization doesn't have a vested interest in being able to adapt
to quickly changing requirements? Conceptualize properly and you'll save
yourself time in the long run and be able to adapt faster with less effort.
From a business need perspective, I can hardly afford to take all of the
required time and resources up front to design an application that will do
everthing I will ever need it to for the end of time. If I thought and
acted
like this, I would be successfully driving my business into the ground.
Nor
can I sit back and do nothing.
It doesn't take as much time as you would think. A lot of it is just
figuring out where you are, where you want to go and the principles that
will guide in getting to your destination. My first app was originally
designed just to capture inquiries and to document the actions and
information gathered concerning the inquiry. Overtime, it was expanded to
support documenting refunds, then generating journal entries and then
eventually invoice collection where the invoices where generated in another
system. The validity of the concept was confirmed in that the fundamental
concepts were so well thought out, it was just a matter of creating the
needed objects. If I have to go back and make a change to initial objects
and tables, the changes were very minimal - typically a new field. You may
want to read up on the concept of design-build in the construction industry.
At the outset of DB project, the specifics, such as carpet color, have not
been determined however the end result is known, a 1 million sqft convention
center. The placement of support columns may not be known as the land is
being cleared, let alone specs for the alarm system.
So it becomes quite obvious to me and anyone else who has a head for
business management that a balance must be struck, and this balance
regarding
application programming requires quick deployment of functionable
utilities
while understanding and designing around the fact that the application is
*not* complete and will in the future be expanded and improved upon.
Yes, but again it's a business decision where you have to consider the
benefit of have it now versus the cost of changing it later.
This type of under-the-gun development one of many concepts that allows my
business to remain successful where we are constantly under-the-gun for
new
changes and challenges from customers and competitors. The understanding
and
ability to work with this type of fast paced business environmnent is why
our
business has grown over 20% in the past three years, where more than half
of
my competitors-in-class have closed thier doors.
If anything this is an argument FOR giving careful thought to
conceptualization and data modeling. First, I would argue that your
*business* has not changed. If you created widgets ten years ago, you're
still creating them today - unless that division is no longer in business.
Even if you've changed products, you're still in the manufacturing business.
What has changed are things such as quality control, service level, delivery
time, delivery method, machines used in production, government regulations
even the scale of your business. If your environment is indeed 'fast paced',
doesn't that mandate that you be able to adapt as fast as possible? A solid
conceptualized approach to your application will enable that in that it will
be proven valid when the application can still be used despite the changing
business environment or regulations. What if instead of having to implement
changes to the code, it was a matter of changing data? The application would
have adapted in moments. That is what a solid conceptualization will buy
you. Its ROI for that matter. Granted, there may have to be coding depending
on the change, but it *will* be less.
So true. Now that I have explained what my business needs are, you can
rest
assured knowing that I have given them some consideration.
At this point you should understand that the nature of my application(s)
is
evolution. This will never change. They are always in a constant state
of
flux, as they need to be.
But again, the fundamental *business* and *business task* won't. There is a
difference between both and organizational policies, regulations, culture
and initiatives.
Next, I would like to discuss the basis of these changes in object names.
In your previous posts, you give examples such as changing "Customers" to
"Customer Information", or changing "Orders" to "Order Details".
These are examples of base level objects. Maybe you do not understand
that
the names of the tables that I am changing are not base level object names
by
any means, but are nested levels deep in a manufacturing management
application with built-in proprietary CAM (Computer Aided Machining)
software, as one example of the highly intuitive integration of the
application. tblCompanies is still tblCompanies, and that has not changed
since the application was written six years ago. tblOrders is still
tblOrders, tblOrderDetails is still tblOrderDetails.
A base level object is as deep conceptually as it gets. If the object is
indeed 'deep', that's all the more reason to accept the object name as-is
without changing it *even if a more descriptive name might be appropriate*.
Although there are tools designed to change object names throughout Access
and Find/Replace does work, you would still need to thoroughly test the
change to ensure that ever change was made. What would happen if the
application with the name change went into production and there was a
serious bug created? The 'deeper' an object the greater the scope of the
impact of any change. Again, we come back to the concept of cost and sound
business decision. Although a table name change might be warranted does the
benefit of a name change outweigh the cost of re-certifying the application
in terms of QA along with the time and effort to actually change the name?
What I am working with at this point in time (the table name that I have
decided to change) is in a very deep part of the application, and is still
under development. Because I do not feel like taking the time to try and
explain a module for CAM integration that lies nearly twenty levels deep
in
table and relationship structures, I will revert back to a change I made
approximately a year after the initial application was introduced for our
Again, if something is that 'deep' you shouldn't be changing names at this
point in the game. It's one of those things that you have to chalk up to
human error or oversight. I have an application where I misspelled a field
name, but given the stage of development of the project and the fields
usage, I left it as-is. The cost of the correction being much, much more
than the cost of the error.
At the initial deployment of the base application, there was functionality
to track information based on manufactured parts (it's what we do...).
Hence
the name of the base table that held the base data was "tblParts". Even
in
the initial development, I was aware that I would later revise this to
handle
all tangible materials. But, keeping keenly in mind my business needs
(the
fact that I needed immediately custom handling for Parts, but not every
tangible object of the business, I opted to not spend the time designing
the
entire materials handling. I did not have that kind of time, and for me
to
spend X amount of hours making sure I had the right table names to reflect
what would later be would have been detrimental to my performance in
keeping
up with pressured requirements.
If at the time of the initial development you knew that the Materials would
have been a more appropriate name, even if the Materials Handling
functionality was way down the road, you should have named the table
Materials. There are plenty of times where what has been conceptualized is
never realized. Case in point, I have an app where one of the fields will
most likely never be used. In my conceptualization, it made sense to have
it, however in development it's become clear that it may not be needed.
However, I am leaving it for now.
Again, if you had spend X hours thinking about the conceptualization, you
would have saved yourself time down the road. Also, when I say
conceptualization that does not mean that you fully map out, document every
last iota of it. You think about the destination down the road and ask is
this decision going to me there sooner. If you had done that, you wouldn't
have to rename the table. Also, you have to ask if you're meeting short-term
goals at the sacrifice of long-term success. It sounds as if your
organization is 'reactive/responsive' as opposed to 'forward-thinking'
making decisions that favor the here and now at the expense of tomorrow.
Also, on a side note, there is no such thing as a 'right' table name. You're
not going to get hauled in front of Congress for using a table names 'Parts'
for 'Materials'. You have to balance the *total* effort to change the table
name against having an application that's perfectly implemented.
Hence, tblParts was born, as tblParts accurately describes the data being
Later, after a year or so, I had the time to expand upon this basic parts
handling to include all tangible materials of the business. tblParts no
longer accurately describes this. tblItems, though, does a much better
job
explaining this evolved feature of the application. Some of the options
that
I had (similar to some of the options that I now face with the
implementation
of CAM software into an existing (and quite stable, I might add)
application)
Will the business go bankrupt if the table remains 'tblParts'? No. Will
having 'materials' in a table named 'parts' stop the users from using the
application, hinder the execution of their job, prevent clients from being
serviced, create financial loss or otherwise halt the operation of the
company? No. Will they know the difference? Never. Does it represent
accurately the records contained therein? No. Can a developer with
reasonable intelligence figure out that it's the table that contains the
base or raw materials? Probably. If a developer can't make that jump, he/she
probably shouldn't be digging around in your data to begin with.
- from the start, design the entire application to handle everything that
I
thought it would ever need (not hardly... no time for this)
It's not about designing it down to the last iota. It's about having a solid
idea of where you're going and then ensuring that the steps you take will
lead you there. If a CEO says that the company will increase its business by
40% in two years, the CEO honestly know the specifics of how that's going to
happen? Nope. He'll have ideas, but not the specifics.
- name the tables of the initial application based on what I thought they
would need to be in the future (no... who's to say that I would remember
what
I had in mind during development if the object names were based on castles
built in clouds? this type of approach is a mess waiting to happen)
The likelihood of your forgetting what your intent was is actually quite
minimal. Name a table 'Materials' and the name itself will end up jogging
your memory. You may not remember specifics, but you'll remember that at one
time you were thinking of a the db handling materials management. Plus, I
would suggest that 'Materials' isn't that far fetch of a name. When you go
to lunch, do you have a soda, a soft drink or a Coke?
- upon evolution of the existing application, keep the table names what
they
were previously named and disregard changing them? (no... this would
certainly make for a nice mess down the road when you are trying to work
with
consumable material data that are wrongly stored in a table called
tblParts)
Again, does the cost of changing the name and validating the code outweigh
the cost of a developer having to remember that the materials are in the
parts table? What would the reasonable developer think? Certainly the DB
won't be conceptually pure, but does it stop the users, the business or even
the developer when all is said and done? At some point, you have to balance
the conceptually purity of an existing database versus the effort it takes
to work with an impure database. If an average developer can figure out and
remember that materials are in the 'parts' table, why bother changing names?
Yes, someone not familiar with the DB will have to poke around, but they'll
have to do that anyways. Developers fully realize that applications and DB's
evolve. Yes, you want to make things as easy as possible for future
developers, but when you're working with a DB that is evolving, there are
times where the cost of making things easy for the developers is outweighed
by the cost. That is way I push for spending time conceptualizing the DB, it
does pay off in the end.
- build the object names to what make sense for the current application,
knowing that a small percentage of these names may change as things evolve
in
the future (bingo! - now, when I refer back to the last deployment, I have
table names that accurately describe the data being held in them. Not
data
that was held in them years ago, not data that *might* be held in them
years
in the future, but data that is *currently* held in them)
Again, you're not going to dramatically change the contents of the table.
You won't be putting payments in an order details table, anything else is
semantics. If a person of reasonable intelligence can figure out that the
table name Materials contains Parts information or vise versus - don't sweat
it that it's not 100% perfect and accurate. What if you decide that
'components' is a more appropriate term than 'materials' or 'parts'? There
is a difference between accurately communication the CONCEPT behind the
table and the actual contents. Yes, the name should follow the contents of
the table and when you do, the concept will be communicated, but that
doesn't mean that the concept won't communication the general contents.
Materials, Parts, and Components all communicate the CONCEPT that the
records represent key items in the construction of a product.
In a two part summary:
You seem to base your argument that table names should not change based on
core tables in an application, such as Customers or Orders. If this were
the
case, I would certainly agree, but alas, it is not so simple.
Furthermore,
it takes a mere minutes to change a table name and get the rest of the
application to accept the change (thanks to think tools that Crystal has
pointed me to). Furthermore, less than 10% of the objects in my
application
ever need this. So please do not assume that I am trying to change
"COMPANIES" to "COMPANY INFORMATION", or perhaps "CI". Just because you
do
not have the insight on my particular situation does not make me an idiot
that does not know how to design an application. In fact, I might make
some
comment now about how some people are so close-minded that they would
never
even consider any of the above, but I'll leave that alone...
Yes, I feel to the core of my being that there is a point where table names
should not be changed. In the example of 'Companies'/'CompanyInformation', I
have seen people here doing just that. Anytime the subject is broached, it
raises an automatic red flag. I had no way of knowing your specifics. Even
though there are tools that will seek out and change object names, that
doesn't preclude you from needing to test the application to confirm that
the changes were successful.
And part two... this is a matter of balance. Not object names. You
should
now fully understand my reasons for requiring the small amount of object
name
changes. It all comes back to business needs, as you said, and demanding
business is always a balance of many things. It is those that do not
understand or are not flexible enough to cope with that balance that are
going to have a hard time in life. This is what it all boils down to.
Modified object names are merely one of hundreds of things that surface
because of this requirement for balance. Understanding and working with
this
balance is why you have people that run successful businesses, or do not.
That is the core of the problem, and that will never change, no matter how
good you think you are. Understanding and accepting that you will never
be
good enough to get everything at once is key to survival.
While I understand the reasoning behind changing an object's name, I do not
feel that it is justified given the cost of doing so. A developer with
average intelligence should be able to figure out and remember that item
such as sheet metal, rubber, lumber, etc, although technically materials,
are stored in a table named Parts. There is a point where you should accept
things as is and while not ideal something to live with. The business will
not grind to a halt.
To further understand the importance of maintaining balance (in business,
in
life, in application programming, and everything else), I might suggest
that
you try some pilot training. Go fly airplanes or helicopters, if you
never
have. This will teach you the importance of balancing in a volitile
environment. If that doesn't do it, well... it probably will no longer be
an
issue for you. If you think that you will always have the upper hand and
nothing will ever change while you're in an airplane, you're well on your
way
into a six foot deep hole (assuming that they can find enough pieces of
you
to bother burying). This requirement for maintaining balance does not
only
apply in aviation, but in everything we do in life. Application
programming
included. Go do this, and take these values that you learn, and apply
them
elsewhere, and I can guarantee that you will be a more proficient
application
And again I reiterate, your ROI for spending time conceptualizing an
application is seen when the time to adapt the application to a changing
environment is reduced when compared to the time it takes to adapt it
without having a solid conceptual foundation turning days into hours, weeks
into days.
"Jack Leach" <dymondjack at hot mail dot com> wrote in message
describes the contents of a table that it would have to be renamed.
Perhaps I can explain the scenario a bit more so that you may understand.
As nice as it would be, this root of this matter that we are discussing
actually has very little to do with the name of objects, but instead a
matter
of business survival. Not a matter of application design, but of business
survival... a far far more important concept than mere object names in an
Luke Chung of FMS Inc writes and article explaining these concepts in
detail, and what we can do to work with them as developers. I will post
the
link to this article, and quote some statements out of it for the purpose
of
this discussion.
Quotes from the article:
"As application developers, we've always been constrained by resources,
time, and budgets, so that's not new. What's new is the heightened focus
on
this, combined with the rapidly changing environment."
"A 50% solution this month may be worth more
than a 100% solution in six months"
"The 100% solution may be irrelevant when it's done"
Regardless of the state of the deliverable when placed into production, it
is in the organization's best interest to have a very solid conceptual
foundation for the solution, even if there are portions of the concept that
are not implemented when the application initially goes live or never
implemented over the course of its lifetime. Yes, conceptualizing the
solution will take time, but show me an example of a business decision, any
decision, where careful thought and analysis *isn't* a part of the decision
making process. Furthermore, skimping on the conceptualization can actually
cost you more in the long run. When you know from day one the direction that
the solution is going to take, or may take, you eliminate the need to go
back and rework things after it goes live. You move to a point where you can
focus on introducing new functionality. If you knew that spending two or
three days conceptualizing the design would save you a ten days later on,
wouldn't you jump at the chance. Yes, it adds more time to the initial
delivery date but in the long haul you end up saving time as the fully
conceptualized design, if well thought out, will allow you to implement
changes faster. When a developer buys up 1,000 acres for a master-planned
community, there's always a high-level design that dictates the development
of the land, even if it's in stages over years. The plan shows the final
design of the community, the placement of apartments, condos, homes,
business districts and roads. The developer just doesn't start building
projects without having an idea of the final result. The Orlando
International Airport was master-planned in the mid-1970's, but actually
built over a 20 year span. Even today the original plan has not been 100%
realized, but its very, very close. If OIA hadn't been master-planned, you'd
see a hodge podge design in its layout, like many other older airports that
have been expanded over the years. Take a look at the layout for McCarran.
Conceptualizing your application does not have to require months and years.
Depending on the scope, it could be a day or two, maybe over the span of
week to allow things to gel, but in the end you'll ultimately save time from
*not* having to go back and change things. The truest test of the validity
of any design ultimately in its flexibility to expand with a minimum of
fundamental changes. Conceptualize correctly and the additional of new
functionality to support changing business requirements will much, much
easier to accomplish.
"Even "perfectly" designed and developed applications may become useless
for
reasons beyond your control. The changing economy, new regulations,
changing
customers, products, or services, etc. can all make a "great" application
irrelevant. Being able to create something quickly, get it in use, and
adjust
it "on the fly" is a powerful skill and philosophy. Especially in these
uncertain times"
"Applications are like living beings. The survivors evolve, the bad ones
go
Myself, I am not an application developer. I am a business manager, and
application development is merely one of the great many tasks that I take
on
to ensure the stability of my business. In my particular industry,
regulations and requirements constantly take on a new face, and over the
past
three years this obstacle has grown exponentially.
Regulations and industry requirements should never be the basis for an
application's design. Yes, that's exactly what I said. Rather, the
application should be based on the business process that it is intended to
support. Processing an order is processing an order. Designing a custom part
for a machine is designing a custom part for a machine. The *process* does
not change. The tools, materials, regulations and standards may. In support
of those things, you design the application to be *compliant*. If you're an
architectural firm designing for both hotels and residences, you design the
application so that the *project* has a classification (hotel/residence) and
that each part/material can be flagged appropriately for use in a hotel,
residence or both. If you're dealing with requirements, you design the
database so that requirements are treated as much as possible as *data*.
Does that mean that you won't have to code in order to enforce
business-rules (requirements), NO? Does that mean that doing so will make it
easier than coding the requirements, NO? It does mean that you will have to
think harder and probably coding more up-front, AND it means that you won't
have to do as much of either down the road.
In the end, it's a trade off that's an inverse relationship. Go for a
shorter time to delivery doing minimal conceptualization now, but spend more
time adapting later or go with a longer time to delivery but spend lesser
time adapting later on. Do you want it *now* or do you want to be able to
quickly adapt in the future? Keep in mind that a 'longer time to delivery'
is not necessarily *years* or *months*. You're trading off the benefit of
having it today at the cost of flexibility for the benefit of flexibility
and getting it next week.
Again, you have to think of the big picture and like any business decision
give it thought and consider the consequences and trade-offs.
My job is not to design a master application that will withstand the tests
of all time, even if nothing were to change. Rather, my job is to provide
functionality under a pressured timeframe that coincides with the demands
of
the industry that I am involved in.
So your organization doesn't have a vested interest in being able to adapt
to quickly changing requirements? Conceptualize properly and you'll save
yourself time in the long run and be able to adapt faster with less effort.
From a business need perspective, I can hardly afford to take all of the
required time and resources up front to design an application that will do
everthing I will ever need it to for the end of time. If I thought and
acted
like this, I would be successfully driving my business into the ground.
Nor
can I sit back and do nothing.
It doesn't take as much time as you would think. A lot of it is just
figuring out where you are, where you want to go and the principles that
will guide in getting to your destination. My first app was originally
designed just to capture inquiries and to document the actions and
information gathered concerning the inquiry. Overtime, it was expanded to
support documenting refunds, then generating journal entries and then
eventually invoice collection where the invoices where generated in another
system. The validity of the concept was confirmed in that the fundamental
concepts were so well thought out, it was just a matter of creating the
needed objects. If I have to go back and make a change to initial objects
and tables, the changes were very minimal - typically a new field. You may
want to read up on the concept of design-build in the construction industry.
At the outset of DB project, the specifics, such as carpet color, have not
been determined however the end result is known, a 1 million sqft convention
center. The placement of support columns may not be known as the land is
being cleared, let alone specs for the alarm system.
So it becomes quite obvious to me and anyone else who has a head for
business management that a balance must be struck, and this balance
regarding
application programming requires quick deployment of functionable
utilities
while understanding and designing around the fact that the application is
*not* complete and will in the future be expanded and improved upon.
Yes, but again it's a business decision where you have to consider the
benefit of have it now versus the cost of changing it later.
This type of under-the-gun development one of many concepts that allows my
business to remain successful where we are constantly under-the-gun for
new
changes and challenges from customers and competitors. The understanding
and
ability to work with this type of fast paced business environmnent is why
our
business has grown over 20% in the past three years, where more than half
of
my competitors-in-class have closed thier doors.
If anything this is an argument FOR giving careful thought to
conceptualization and data modeling. First, I would argue that your
*business* has not changed. If you created widgets ten years ago, you're
still creating them today - unless that division is no longer in business.
Even if you've changed products, you're still in the manufacturing business.
What has changed are things such as quality control, service level, delivery
time, delivery method, machines used in production, government regulations
even the scale of your business. If your environment is indeed 'fast paced',
doesn't that mandate that you be able to adapt as fast as possible? A solid
conceptualized approach to your application will enable that in that it will
be proven valid when the application can still be used despite the changing
business environment or regulations. What if instead of having to implement
changes to the code, it was a matter of changing data? The application would
have adapted in moments. That is what a solid conceptualization will buy
you. Its ROI for that matter. Granted, there may have to be coding depending
on the change, but it *will* be less.
So true. Now that I have explained what my business needs are, you can
rest
assured knowing that I have given them some consideration.
At this point you should understand that the nature of my application(s)
is
evolution. This will never change. They are always in a constant state
of
flux, as they need to be.
But again, the fundamental *business* and *business task* won't. There is a
difference between both and organizational policies, regulations, culture
and initiatives.
Next, I would like to discuss the basis of these changes in object names.
In your previous posts, you give examples such as changing "Customers" to
"Customer Information", or changing "Orders" to "Order Details".
These are examples of base level objects. Maybe you do not understand
that
the names of the tables that I am changing are not base level object names
by
any means, but are nested levels deep in a manufacturing management
application with built-in proprietary CAM (Computer Aided Machining)
software, as one example of the highly intuitive integration of the
application. tblCompanies is still tblCompanies, and that has not changed
since the application was written six years ago. tblOrders is still
tblOrders, tblOrderDetails is still tblOrderDetails.
A base level object is as deep conceptually as it gets. If the object is
indeed 'deep', that's all the more reason to accept the object name as-is
without changing it *even if a more descriptive name might be appropriate*.
Although there are tools designed to change object names throughout Access
and Find/Replace does work, you would still need to thoroughly test the
change to ensure that ever change was made. What would happen if the
application with the name change went into production and there was a
serious bug created? The 'deeper' an object the greater the scope of the
impact of any change. Again, we come back to the concept of cost and sound
business decision. Although a table name change might be warranted does the
benefit of a name change outweigh the cost of re-certifying the application
in terms of QA along with the time and effort to actually change the name?
What I am working with at this point in time (the table name that I have
decided to change) is in a very deep part of the application, and is still
under development. Because I do not feel like taking the time to try and
explain a module for CAM integration that lies nearly twenty levels deep
in
table and relationship structures, I will revert back to a change I made
approximately a year after the initial application was introduced for our
Again, if something is that 'deep' you shouldn't be changing names at this
point in the game. It's one of those things that you have to chalk up to
human error or oversight. I have an application where I misspelled a field
name, but given the stage of development of the project and the fields
usage, I left it as-is. The cost of the correction being much, much more
than the cost of the error.
At the initial deployment of the base application, there was functionality
to track information based on manufactured parts (it's what we do...).
Hence
the name of the base table that held the base data was "tblParts". Even
in
the initial development, I was aware that I would later revise this to
handle
all tangible materials. But, keeping keenly in mind my business needs
(the
fact that I needed immediately custom handling for Parts, but not every
tangible object of the business, I opted to not spend the time designing
the
entire materials handling. I did not have that kind of time, and for me
to
spend X amount of hours making sure I had the right table names to reflect
what would later be would have been detrimental to my performance in
keeping
up with pressured requirements.
If at the time of the initial development you knew that the Materials would
have been a more appropriate name, even if the Materials Handling
functionality was way down the road, you should have named the table
Materials. There are plenty of times where what has been conceptualized is
never realized. Case in point, I have an app where one of the fields will
most likely never be used. In my conceptualization, it made sense to have
it, however in development it's become clear that it may not be needed.
However, I am leaving it for now.
Again, if you had spend X hours thinking about the conceptualization, you
would have saved yourself time down the road. Also, when I say
conceptualization that does not mean that you fully map out, document every
last iota of it. You think about the destination down the road and ask is
this decision going to me there sooner. If you had done that, you wouldn't
have to rename the table. Also, you have to ask if you're meeting short-term
goals at the sacrifice of long-term success. It sounds as if your
organization is 'reactive/responsive' as opposed to 'forward-thinking'
making decisions that favor the here and now at the expense of tomorrow.
Also, on a side note, there is no such thing as a 'right' table name. You're
not going to get hauled in front of Congress for using a table names 'Parts'
for 'Materials'. You have to balance the *total* effort to change the table
name against having an application that's perfectly implemented.
Hence, tblParts was born, as tblParts accurately describes the data being
Later, after a year or so, I had the time to expand upon this basic parts
handling to include all tangible materials of the business. tblParts no
longer accurately describes this. tblItems, though, does a much better
job
explaining this evolved feature of the application. Some of the options
that
I had (similar to some of the options that I now face with the
implementation
of CAM software into an existing (and quite stable, I might add)
application)
Will the business go bankrupt if the table remains 'tblParts'? No. Will
having 'materials' in a table named 'parts' stop the users from using the
application, hinder the execution of their job, prevent clients from being
serviced, create financial loss or otherwise halt the operation of the
company? No. Will they know the difference? Never. Does it represent
accurately the records contained therein? No. Can a developer with
reasonable intelligence figure out that it's the table that contains the
base or raw materials? Probably. If a developer can't make that jump, he/she
probably shouldn't be digging around in your data to begin with.
- from the start, design the entire application to handle everything that
I
thought it would ever need (not hardly... no time for this)
It's not about designing it down to the last iota. It's about having a solid
idea of where you're going and then ensuring that the steps you take will
lead you there. If a CEO says that the company will increase its business by
40% in two years, the CEO honestly know the specifics of how that's going to
happen? Nope. He'll have ideas, but not the specifics.
- name the tables of the initial application based on what I thought they
would need to be in the future (no... who's to say that I would remember
what
I had in mind during development if the object names were based on castles
built in clouds? this type of approach is a mess waiting to happen)
The likelihood of your forgetting what your intent was is actually quite
minimal. Name a table 'Materials' and the name itself will end up jogging
your memory. You may not remember specifics, but you'll remember that at one
time you were thinking of a the db handling materials management. Plus, I
would suggest that 'Materials' isn't that far fetch of a name. When you go
to lunch, do you have a soda, a soft drink or a Coke?
- upon evolution of the existing application, keep the table names what
they
were previously named and disregard changing them? (no... this would
certainly make for a nice mess down the road when you are trying to work
with
consumable material data that are wrongly stored in a table called
tblParts)
Again, does the cost of changing the name and validating the code outweigh
the cost of a developer having to remember that the materials are in the
parts table? What would the reasonable developer think? Certainly the DB
won't be conceptually pure, but does it stop the users, the business or even
the developer when all is said and done? At some point, you have to balance
the conceptually purity of an existing database versus the effort it takes
to work with an impure database. If an average developer can figure out and
remember that materials are in the 'parts' table, why bother changing names?
Yes, someone not familiar with the DB will have to poke around, but they'll
have to do that anyways. Developers fully realize that applications and DB's
evolve. Yes, you want to make things as easy as possible for future
developers, but when you're working with a DB that is evolving, there are
times where the cost of making things easy for the developers is outweighed
by the cost. That is way I push for spending time conceptualizing the DB, it
does pay off in the end.
- build the object names to what make sense for the current application,
knowing that a small percentage of these names may change as things evolve
in
the future (bingo! - now, when I refer back to the last deployment, I have
table names that accurately describe the data being held in them. Not
data
that was held in them years ago, not data that *might* be held in them
years
in the future, but data that is *currently* held in them)
Again, you're not going to dramatically change the contents of the table.
You won't be putting payments in an order details table, anything else is
semantics. If a person of reasonable intelligence can figure out that the
table name Materials contains Parts information or vise versus - don't sweat
it that it's not 100% perfect and accurate. What if you decide that
'components' is a more appropriate term than 'materials' or 'parts'? There
is a difference between accurately communication the CONCEPT behind the
table and the actual contents. Yes, the name should follow the contents of
the table and when you do, the concept will be communicated, but that
doesn't mean that the concept won't communication the general contents.
Materials, Parts, and Components all communicate the CONCEPT that the
records represent key items in the construction of a product.
In a two part summary:
You seem to base your argument that table names should not change based on
core tables in an application, such as Customers or Orders. If this were
the
case, I would certainly agree, but alas, it is not so simple.
Furthermore,
it takes a mere minutes to change a table name and get the rest of the
application to accept the change (thanks to think tools that Crystal has
pointed me to). Furthermore, less than 10% of the objects in my
application
ever need this. So please do not assume that I am trying to change
"COMPANIES" to "COMPANY INFORMATION", or perhaps "CI". Just because you
do
not have the insight on my particular situation does not make me an idiot
that does not know how to design an application. In fact, I might make
some
comment now about how some people are so close-minded that they would
never
even consider any of the above, but I'll leave that alone...
Yes, I feel to the core of my being that there is a point where table names
should not be changed. In the example of 'Companies'/'CompanyInformation', I
have seen people here doing just that. Anytime the subject is broached, it
raises an automatic red flag. I had no way of knowing your specifics. Even
though there are tools that will seek out and change object names, that
doesn't preclude you from needing to test the application to confirm that
the changes were successful.
And part two... this is a matter of balance. Not object names. You
should
now fully understand my reasons for requiring the small amount of object
name
changes. It all comes back to business needs, as you said, and demanding
business is always a balance of many things. It is those that do not
understand or are not flexible enough to cope with that balance that are
going to have a hard time in life. This is what it all boils down to.
Modified object names are merely one of hundreds of things that surface
because of this requirement for balance. Understanding and working with
this
balance is why you have people that run successful businesses, or do not.
That is the core of the problem, and that will never change, no matter how
good you think you are. Understanding and accepting that you will never
be
good enough to get everything at once is key to survival.
While I understand the reasoning behind changing an object's name, I do not
feel that it is justified given the cost of doing so. A developer with
average intelligence should be able to figure out and remember that item
such as sheet metal, rubber, lumber, etc, although technically materials,
are stored in a table named Parts. There is a point where you should accept
things as is and while not ideal something to live with. The business will
not grind to a halt.
To further understand the importance of maintaining balance (in business,
in
life, in application programming, and everything else), I might suggest
that
you try some pilot training. Go fly airplanes or helicopters, if you
never
have. This will teach you the importance of balancing in a volitile
environment. If that doesn't do it, well... it probably will no longer be
an
issue for you. If you think that you will always have the upper hand and
nothing will ever change while you're in an airplane, you're well on your
way
into a six foot deep hole (assuming that they can find enough pieces of
you
to bother burying). This requirement for maintaining balance does not
only
apply in aviation, but in everything we do in life. Application
programming
included. Go do this, and take these values that you learn, and apply
them
elsewhere, and I can guarantee that you will be a more proficient
application
And again I reiterate, your ROI for spending time conceptualizing an
application is seen when the time to adapt the application to a changing
environment is reduced when compared to the time it takes to adapt it
without having a solid conceptual foundation turning days into hours, weeks
into days.
Jack Leach
"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
David C. Holley said:
Even though applications do evolve, you're not going to start storing
PART
information in an ORDERS table. Explain to me why if 'ORDERS' accurately
describes the contents of a table that it would have to be renamed.
Furthermore (and more importantly), even if a more descriptive name is
developed such as 'CUSTOMER ORDERS', it begs the question if there is a
specific BUSINESS NEED to change the table name. Even if the table name
is
mispelled as in 'ORDRES' , the mispelling does not rise to the level of
BUSINESS NEED and thus warrant a name change.
Even if you go to a Header/Detail model for customer orders where the
content of the ORDERS table will be the order detail, it does not
neccessarily warrant changing the name from 'ORDERS' to 'ORDER DETAILS'.
Yes, ORDER DETAILS in that scenario would be [more] descriptive, however
it
all comes back to BUSINESS NEED. Will the DB still function if the table
is
named 'ORDERS' although 'ORDER DETAILS' is more specific? Do you choose
to
spend the time and effort to rename the table or is it just a matter of
the
developer(s) knowing that ORDERS is actually ORDER DETAILS? Which costs
more
in terms of labor? Will the DB cease to function if the table isn't
renamed?
Jack Leach said:
Some applications do have a tendancy to evolve. Not everyone has the
luxury
of knowing exactly what they are going to need 10 years from now, and
when
the time comes to improve upon an old design, often things aren't
previously
what would be ideal presently.
--
Jack Leach
www.tristatemachine.com
"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
:
But how much time had you spent having to re-code as the result of
changing
a single file name?
Furthermore, if you have a table that's containing customer
information,
why
isn't is name 'Customers' or 'CustomerInformation' to begin with? The
table
name should follow the contents of the table.
Hi David,
Personally I disagree that changing names is a sign of poor design.
When
I first design an application, I try very hard to create the final
names -- but there are often times where I think of something better
and
change them.
I also work with applications that other folks designed, a lot!
Changing
names is something I tend to do quite a bit -- in those cases,
usually
so
much changes that we rewrite the code and redesign forms/reports
too --
and your statement would surely be applicable, but changed names
don't
really matter.
Warm Regards,
Crystal
remote programming and training
http://MSAccessGurus.com
free video tutorials
http://www.YouTube.com/user/LearnAccessByCrystal
Access Basics
http://www.AccessMVP.com/strive4peace
free 100-page book that covers essentials in Access
(also includes links for Whistles and Bells, VBA chapters, sample
databases, etc)
*
have an awesome day
*
David C. Holley wrote:
There are those that would suggest that the need to change a table
name
is an indication of a poor design at the outset.
.
.
