Database Documentation

I would be interested in hearing what tools people have used to document the
business uses of tables in a database? I have looked at the meta data
services that comes with SQL Server, and while it looks like a good tool, I
do not think that it fits particularly well with what I am looking to
accomplish. I would like to have some documentation that outlines the
business uses of/business rules for each table in the database. Almost an
ERD, but something that discusses/shows information about the business model
that the database/system(s) were constructed to support.
Any advice is appreciated!
TimHello Tim,
This might not be what you are looking for but maybe it can be. I've started
a project which is intended to help people with their network documentation.
The output is to Microsoft word.
The project has two files, one for documenting Servers in general and one
for documenting SQL-Servers. I've just started with the SQL version so there
are a lot of things that can be added.
If you are interested in the project you can find information here:
http://sydi.sourceforge.net
If you want to add feature requests you can do so here:
http://sourceforge.net/tracker/?group_id=116471&atid=674897
Best regards
Patrick
"TimS" <timstspry@.msn.com(donotspam)> wrote in message
news:77AD57C8-C893-41D7-B200-38435DB2D11A@.microsoft.com...
> I would be interested in hearing what tools people have used to document
the
> business uses of tables in a database? I have looked at the meta data
> services that comes with SQL Server, and while it looks like a good tool,
I
> do not think that it fits particularly well with what I am looking to
> accomplish. I would like to have some documentation that outlines the
> business uses of/business rules for each table in the database. Almost an
> ERD, but something that discusses/shows information about the business
model
> that the database/system(s) were constructed to support.
> Any advice is appreciated!
> Tim|||Hi Tim,
Here is what we have done. In our database we have two "extra tables" One
that describes the tables and one that describes individual fields
(columns). The fields table has a foreign key back to the tables table so
that fields can be associated with their proper table. In those tables we
have columns that are used to describe the individual tables and fields.
Things like business rules, uses etc. We then have a set of web pages that
connect to an empty version of the database that has only this meta data
information in it. Everyone can use them to view and update this
information. Each time a new version of the DB comes out we have an
automated process that creates a new empty DB, copies the two tables of meta
data from the existing DB and then updates the metadata tables with the
updates to the schema (updated tables & colums). The existing DB then gets
replaced with the updated DB and the web pages now use this.
Wayne
"TimS" <timstspry@.msn.com(donotspam)> wrote in message
news:77AD57C8-C893-41D7-B200-38435DB2D11A@.microsoft.com...
>I would be interested in hearing what tools people have used to document
>the
> business uses of tables in a database? I have looked at the meta data
> services that comes with SQL Server, and while it looks like a good tool,
> I
> do not think that it fits particularly well with what I am looking to
> accomplish. I would like to have some documentation that outlines the
> business uses of/business rules for each table in the database. Almost an
> ERD, but something that discusses/shows information about the business
> model
> that the database/system(s) were constructed to support.
> Any advice is appreciated!
> Tim|||SchemaToDoc (http://www.schematodoc.com) lets you annotate the tables and
fields in your database. It then lets you export the structure of your
database (tables, fields, indexes, check constraints, foreign key
constraints, and triggers) as well as your annotations to a Word document.
"Patrick Ogenstad" <patrick.ogenstad@.netsafe.se> wrote in message
news:uoeqjdgoEHA.1272@.TK2MSFTNGP09.phx.gbl...
> Hello Tim,
>
> This might not be what you are looking for but maybe it can be. I've
started
> a project which is intended to help people with their network
documentation.
> The output is to Microsoft word.
>
> The project has two files, one for documenting Servers in general and one
> for documenting SQL-Servers. I've just started with the SQL version so
there
> are a lot of things that can be added.
>
> If you are interested in the project you can find information here:
> http://sydi.sourceforge.net
>
> If you want to add feature requests you can do so here:
> http://sourceforge.net/tracker/?group_id=116471&atid=674897
>
> Best regards
> Patrick
>
> "TimS" <timstspry@.msn.com(donotspam)> wrote in message
> news:77AD57C8-C893-41D7-B200-38435DB2D11A@.microsoft.com...
> > I would be interested in hearing what tools people have used to document
> the
> > business uses of tables in a database? I have looked at the meta data
> > services that comes with SQL Server, and while it looks like a good
tool,
> I
> > do not think that it fits particularly well with what I am looking to
> > accomplish. I would like to have some documentation that outlines the
> > business uses of/business rules for each table in the database. Almost
an
> > ERD, but something that discusses/shows information about the business
> model
> > that the database/system(s) were constructed to support.
> >
> > Any advice is appreciated!
> >
> > Tim
>

Database Design Question

I am right now in process of designing a database for hosting business. Now
just like other hosting companies even this hosting companies has its
different web hosting packages. But besides that the company is going to
provide a feature to customer where in they can select/customize the package
wherein they might want to add one of two additional feature that are not a
part of the standard package.
I have designed most of that tables but i am confused on how exactly should
i design the "User Defined Package" table.
There are one of the two things that i can do.
1) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have a "featureid" (integer datatype) column that
would be referencing "Features" table.
The problem here is that it would be easily be managable from programming
aspect but there wil be redundancy factor since if a same customer takes 5
additional features then there would be 5 rows with same customer id and
separate featureid and this is just for one customer. If there is a large
customer base it could create space issues as well.
2) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have another column featureids (varchar datatype)
that would have all the additional feature ids seperated by a deliminator.
There won't be redundancy in this case but would make things little bit
complicated from programming aspect since everything new additional feature
to to be added or edited or to be removed will require some work in the
code.
Which method should i go for that would be helpful not just now but also in
future as the customer base increases.
I do not have anything else in mind. If there is any other solution to this
all the suggestions are welcomed.
Thank you
Niel
Niel wrote:
> I am right now in process of designing a database for hosting business. Now
> just like other hosting companies even this hosting companies has its
> different web hosting packages. But besides that the company is going to
> provide a feature to customer where in they can select/customize the package
> wherein they might want to add one of two additional feature that are not a
> part of the standard package.
> I have designed most of that tables but i am confused on how exactly should
> i design the "User Defined Package" table.
> There are one of the two things that i can do.
> 1) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have a "featureid" (integer datatype) column that
> would be referencing "Features" table.
> The problem here is that it would be easily be managable from programming
> aspect but there wil be redundancy factor since if a same customer takes 5
> additional features then there would be 5 rows with same customer id and
> separate featureid and this is just for one customer. If there is a large
> customer base it could create space issues as well.
> 2) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have another column featureids (varchar datatype)
> that would have all the additional feature ids seperated by a deliminator.
> There won't be redundancy in this case but would make things little bit
> complicated from programming aspect since everything new additional feature
> to to be added or edited or to be removed will require some work in the
> code.
> Which method should i go for that would be helpful not just now but also in
> future as the customer base increases.
> I do not have anything else in mind. If there is any other solution to this
> all the suggestions are welcomed.
> Thank you
> Niel
I recommend you study some books or take a course on database design
theory before you go further. Your option 2 is a textbook example of
how NOT to do it.
Your first option sounds right to me from the point of view of
scalability and integrity. Of course I haven't had the opportunity to
analyse your business requirements, I only have your narrative to go
on. That's why newsgroups are a poor place to get database design
advice.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
|||Thanks for the suggestion david,
I'll go ahead and have a look at few book for reference. Can you advise me
on any good places/tutorials on website that i can go through to get a clear
concept on this.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1143574016.274320.221210@.v46g2000cwv.googlegr oups.com...[vbcol=seagreen]
> Niel wrote:
Now[vbcol=seagreen]
package[vbcol=seagreen]
not a[vbcol=seagreen]
should[vbcol=seagreen]
referencing[vbcol=seagreen]
that[vbcol=seagreen]
programming[vbcol=seagreen]
5[vbcol=seagreen]
large[vbcol=seagreen]
referencing[vbcol=seagreen]
datatype)[vbcol=seagreen]
deliminator.[vbcol=seagreen]
feature[vbcol=seagreen]
in[vbcol=seagreen]
this
> I recommend you study some books or take a course on database design
> theory before you go further. Your option 2 is a textbook example of
> how NOT to do it.
> Your first option sounds right to me from the point of view of
> scalability and integrity. Of course I haven't had the opportunity to
> analyse your business requirements, I only have your narrative to go
> on. That's why newsgroups are a poor place to get database design
> advice.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>

Database Design Question

I am right now in process of designing a database for hosting business. Now
just like other hosting companies even this hosting companies has its
different web hosting packages. But besides that the company is going to
provide a feature to customer where in they can select/customize the package
wherein they might want to add one of two additional feature that are not a
part of the standard package.
I have designed most of that tables but i am confused on how exactly should
i design the "User Defined Package" table.
There are one of the two things that i can do.
1) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have a "featureid" (integer datatype) column that
would be referencing "Features" table.
The problem here is that it would be easily be managable from programming
aspect but there wil be redundancy factor since if a same customer takes 5
additional features then there would be 5 rows with same customer id and
separate featureid and this is just for one customer. If there is a large
customer base it could create space issues as well.
2) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have another column featureids (varchar datatype)
that would have all the additional feature ids seperated by a deliminator.
There won't be redundancy in this case but would make things little bit
complicated from programming aspect since everything new additional feature
to to be added or edited or to be removed will require some work in the
code.
Which method should i go for that would be helpful not just now but also in
future as the customer base increases.
I do not have anything else in mind. If there is any other solution to this
all the suggestions are welcomed.
Thank you
NielNiel wrote:
> I am right now in process of designing a database for hosting business. No
w
> just like other hosting companies even this hosting companies has its
> different web hosting packages. But besides that the company is going to
> provide a feature to customer where in they can select/customize the packa
ge
> wherein they might want to add one of two additional feature that are not
a
> part of the standard package.
> I have designed most of that tables but i am confused on how exactly shoul
d
> i design the "User Defined Package" table.
> There are one of the two things that i can do.
> 1) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have a "featureid" (integer datatype) column tha
t
> would be referencing "Features" table.
> The problem here is that it would be easily be managable from programming
> aspect but there wil be redundancy factor since if a same customer takes 5
> additional features then there would be 5 rows with same customer id and
> separate featureid and this is just for one customer. If there is a large
> customer base it could create space issues as well.
> 2) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have another column featureids (varchar datatype
)
> that would have all the additional feature ids seperated by a deliminator.
> There won't be redundancy in this case but would make things little bit
> complicated from programming aspect since everything new additional featur
e
> to to be added or edited or to be removed will require some work in the
> code.
> Which method should i go for that would be helpful not just now but also i
n
> future as the customer base increases.
> I do not have anything else in mind. If there is any other solution to thi
s
> all the suggestions are welcomed.
> Thank you
> Niel
I recommend you study some books or take a course on database design
theory before you go further. Your option 2 is a textbook example of
how NOT to do it.
Your first option sounds right to me from the point of view of
scalability and integrity. Of course I haven't had the opportunity to
analyse your business requirements, I only have your narrative to go
on. That's why newsgroups are a poor place to get database design
advice.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Thanks for the suggestion david,
I'll go ahead and have a look at few book for reference. Can you advise me
on any good places/tutorials on website that i can go through to get a clear
concept on this.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1143574016.274320.221210@.v46g2000cwv.googlegroups.com...
> Niel wrote:
Now[vbcol=seagreen]
package[vbcol=seagreen]
not a[vbcol=seagreen]
should[vbcol=seagreen]
referencing[vbcol=seagreen]
that[vbcol=seagreen]
programming[vbcol=seagreen]
5[vbcol=seagreen]
large[vbcol=seagreen]
referencing[vbcol=seagreen]
datatype)[vbcol=seagreen]
deliminator.[vbcol=seagreen]
feature[vbcol=seagreen]
in[vbcol=seagreen]
this[vbcol=seagreen]
> I recommend you study some books or take a course on database design
> theory before you go further. Your option 2 is a textbook example of
> how NOT to do it.
> Your first option sounds right to me from the point of view of
> scalability and integrity. Of course I haven't had the opportunity to
> analyse your business requirements, I only have your narrative to go
> on. That's why newsgroups are a poor place to get database design
> advice.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>

Database Design Question

I am right now in process of designing a database for hosting business. Now
just like other hosting companies even this hosting companies has its
different web hosting packages. But besides that the company is going to
provide a feature to customer where in they can select/customize the package
wherein they might want to add one of two additional feature that are not a
part of the standard package.
I have designed most of that tables but i am confused on how exactly should
i design the "User Defined Package" table.
There are one of the two things that i can do.
1) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have a "featureid" (integer datatype) column that
would be referencing "Features" table.
The problem here is that it would be easily be managable from programming
aspect but there wil be redundancy factor since if a same customer takes 5
additional features then there would be 5 rows with same customer id and
separate featureid and this is just for one customer. If there is a large
customer base it could create space issues as well.
2) Have a column "customerid" (integer datatype) that will be referencing
to the customer table and have another column featureids (varchar datatype)
that would have all the additional feature ids seperated by a deliminator.
There won't be redundancy in this case but would make things little bit
complicated from programming aspect since everything new additional feature
to to be added or edited or to be removed will require some work in the
code.
Which method should i go for that would be helpful not just now but also in
future as the customer base increases.
I do not have anything else in mind. If there is any other solution to this
all the suggestions are welcomed.
Thank you
NielNiel wrote:
> I am right now in process of designing a database for hosting business. Now
> just like other hosting companies even this hosting companies has its
> different web hosting packages. But besides that the company is going to
> provide a feature to customer where in they can select/customize the package
> wherein they might want to add one of two additional feature that are not a
> part of the standard package.
> I have designed most of that tables but i am confused on how exactly should
> i design the "User Defined Package" table.
> There are one of the two things that i can do.
> 1) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have a "featureid" (integer datatype) column that
> would be referencing "Features" table.
> The problem here is that it would be easily be managable from programming
> aspect but there wil be redundancy factor since if a same customer takes 5
> additional features then there would be 5 rows with same customer id and
> separate featureid and this is just for one customer. If there is a large
> customer base it could create space issues as well.
> 2) Have a column "customerid" (integer datatype) that will be referencing
> to the customer table and have another column featureids (varchar datatype)
> that would have all the additional feature ids seperated by a deliminator.
> There won't be redundancy in this case but would make things little bit
> complicated from programming aspect since everything new additional feature
> to to be added or edited or to be removed will require some work in the
> code.
> Which method should i go for that would be helpful not just now but also in
> future as the customer base increases.
> I do not have anything else in mind. If there is any other solution to this
> all the suggestions are welcomed.
> Thank you
> Niel
I recommend you study some books or take a course on database design
theory before you go further. Your option 2 is a textbook example of
how NOT to do it.
Your first option sounds right to me from the point of view of
scalability and integrity. Of course I haven't had the opportunity to
analyse your business requirements, I only have your narrative to go
on. That's why newsgroups are a poor place to get database design
advice.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Thanks for the suggestion david,
I'll go ahead and have a look at few book for reference. Can you advise me
on any good places/tutorials on website that i can go through to get a clear
concept on this.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1143574016.274320.221210@.v46g2000cwv.googlegroups.com...
> Niel wrote:
> > I am right now in process of designing a database for hosting business.
Now
> > just like other hosting companies even this hosting companies has its
> > different web hosting packages. But besides that the company is going to
> > provide a feature to customer where in they can select/customize the
package
> > wherein they might want to add one of two additional feature that are
not a
> > part of the standard package.
> > I have designed most of that tables but i am confused on how exactly
should
> > i design the "User Defined Package" table.
> > There are one of the two things that i can do.
> >
> > 1) Have a column "customerid" (integer datatype) that will be
referencing
> > to the customer table and have a "featureid" (integer datatype) column
that
> > would be referencing "Features" table.
> > The problem here is that it would be easily be managable from
programming
> > aspect but there wil be redundancy factor since if a same customer takes
5
> > additional features then there would be 5 rows with same customer id and
> > separate featureid and this is just for one customer. If there is a
large
> > customer base it could create space issues as well.
> >
> > 2) Have a column "customerid" (integer datatype) that will be
referencing
> > to the customer table and have another column featureids (varchar
datatype)
> > that would have all the additional feature ids seperated by a
deliminator.
> > There won't be redundancy in this case but would make things little bit
> > complicated from programming aspect since everything new additional
feature
> > to to be added or edited or to be removed will require some work in the
> > code.
> >
> > Which method should i go for that would be helpful not just now but also
in
> > future as the customer base increases.
> >
> > I do not have anything else in mind. If there is any other solution to
this
> > all the suggestions are welcomed.
> >
> > Thank you
> > Niel
> I recommend you study some books or take a course on database design
> theory before you go further. Your option 2 is a textbook example of
> how NOT to do it.
> Your first option sounds right to me from the point of view of
> scalability and integrity. Of course I haven't had the opportunity to
> analyse your business requirements, I only have your narrative to go
> on. That's why newsgroups are a poor place to get database design
> advice.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>