I am interested in collecting code to create database tables for
standard commercial information such as employeee tables, customer
tables, transaction tables, and related queries.

Thanks.

"Reporter" <TruckSafety (AT) gmail (DOT) com> wrote

You'd be wasting your time. Creating a table is a trivial task that takes a
few minutes. Understanding your business processes well enough to design a
table that represents all (and only) the kinds of statements you can make
about your business is the hard part. And you would have to do that whether
you intend making the slight effort to define the table yourself, or you
expect just to verify that some "standard" design is indeed a correct fit
for your business.

Even if it were a good idea in principle, you'd probably need to have a
collection of code to create *sets of tables*, so that column names and data
types are properly harmonized.

You probably would be best off to just buy some shrink-wrapped application
package(s) that suits your business, or which your business can be
re-engineered to use.

Roy

"Reporter" <TruckSafety (AT) gmail (DOT) com> wrote

What Roy Hann said.

However, there are some reasonably common data models at
www.databaseanswers.org that can be used as a starting point.

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote:

sentence. Having a list of all the fields that might appear in a table
could prompt someone into asking the right questions in the analysis
phase.

"David Segall" <david (AT) address (DOT) invalid> wrote

I don't disagree particularly with you either, but perhaps a just list of
suggested attributes to consider would be much better for that purpose. A
table creation script would probably obscure any useful information with
(inevitably) cryptic column names and premature suggestions of data types.
(Not to mention equally premature suggestions of various kinds of
constraints.)

Roy

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote

analysis, resulting in a conceptual data model. ER modeling was good enough
for me. (I can't speak for Bobby McGee.) In a sense, that agrees with your
comment, since the "entities" and "relationships" are only there to provide
context for the attributes, and ER model is very much like a list of
attributes. However, matching attributes to the correct entity or attribute
is a kind of prelude to the data normalizing done in the next step.

Database design can be broken into two stages, namely logical design and
physical design.

A table creation script (along with the creation of all those other things)
is an outcome of physical design. I agree with you that coming up with a
table creation script during data analysis is premature.

Also, if you are forced to go back and revisit data analysis after the
design is complete, you generally won't have to rework the entire design,
but rather only a small part of it.

Just my 2 cents.

On Jul 1, 6:23 pm, Reporter <TruckSaf... (AT) gmail (DOT) com> wrote:
I would be interested in extending my DBSchema::Sample -
http://search.cpan.org/~tbone/DBSchema-Sample-1.8/

with code for commercial databases gladly.