Explain to me why if 'ORDERS' accurately
describes the contents of a table that it would have to be renamed.
Ok...
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
application.
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.
http://www.fmsinc.com/tpapers/budgets/ApplicationDevelopment.html
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"
"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
extinct"
----------------
Myself, I am not an application developer. I am a business manager, and
application developement 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 expotentially.
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.
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.
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.
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.
however it all comes back to BUSINESS NEED.
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.
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.
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
business.
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.
Hence, tblParts was born, as tblParts accurately describes the data being
held.
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)
are as follows...
- from the start, design the entire application to handle everything that I
thought it would ever need (not hardly... no time for this)
- 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)
- 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)
- 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)
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...
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.
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
developer afterwords.
--
Jack Leach
www.tristatemachine.com
"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)
.
have an awesome day 
happy to help