Database distribution

Hi,
I am going to distribute a webb site and need to distribute the databases used by this webbsite. A newbie as I am to databases I ask if there is any tool to extract the databases from my machine, store it on a CD and then install it on another machine.
Thing is... I want to distribute the databases, but not the data currently stored in it.

Gudday!1. No such a tool as I know.
2. Backup your database and restore it with different name.
3. DROP TABLEs unusable to user (all user tables), analytic tables ...
4. In this database, use DELETE/TRUNCATE TABLE statements (See BOL) to clear your tables. If you use some tables for configuration, you cannot delete them !!!
5. Select distribution type BACKUP/Script. Script (made for example by EM) is most version compatible, but it takes some time to create it, if you distibute also data.
6. BACKUP installation files for testing UPGRADE.
7. Installation of database on user side can be done by runing script by isql.exe by installation program ( most use InstallShield )
8. Installation is a nightmare of each advanced developer:mad:|||Is it possible to use method of detaching the database, copy the files, distribute files and finally attach the database on remote site?

// Dobaz|||I have a similar situation in my company.I had gone for creating the scripts of the database ,since i also needed the data in the database, the size of the database file was too big .
if u script the database u have total control over it .|||You can use a outer program to restore the database during the installitaion or the program's first running.|||Thanks for all replies and help!

I have tried to:

1. Detached the databases that needs to be distributed from the SQL Server on my original machine.

2. Copied the .mdf and .ldf files from the MSSQL data folder onto a second machine.

3. Attached the distributed databases to SQL Server on the second machine.

It all seems to work ok between my own machines... Maybe this is a good way to go?

As I mentioned eariler I want to distribute the databases to keep table structure intact and only some example data stored in it (i.e. database files will be pretty small).

Database Design - newbie question

Hi ,
First of all my apologies for this very basic question but I can n't find a
definite answers to this question.
I'm new to data warehousing and have started reading "The Data Warehouse
Lifecycle Toolkit" by Kimbal (and others). From it I understood that the
database in your application (normalised) is very differenent to the one in
your warehouse (denormalised). But from reading about SQL Server analysis
server it does n't seem to matter what you use as your source as you can
create your cubes from an application database design.
Is this right? are there any drawbacks to this. It would mean that we won't
need another table design for our warehouse database.
Thanks,
Nuala
What differentiates the data warehouse design from the online transactional
database is the following:
1. To optimize the OLTP database, historical records are often migrated
to the warehouse, and it is from here that trend reports / analysis are
generated. Also, the indexing on the warehouse is optimized for analysis
purposes. The warehouse typically has much more indexing.
2. The warehouse databases are typically located on a different server
that is used exclusively for reporting and analysis. This reduces the load
on the OLTP server.
3. To improve the performace of analysis, data in the warehouse may be
stored in multiple levels of summarization, and most analysis may only be
derived from the smaller summarized datasets.
So the idea of data warehousing is that you perform your analysis against
summarized and highly indexed data instead of at the transactional level.
"Nuala" <nuala.cullen@.prnewswire.co.uk> wrote in message
news:BE655942-E657-46BF-AEAD-9A607AEEAB6F@.microsoft.com...
> Hi ,
> First of all my apologies for this very basic question but I can n't find
a
> definite answers to this question.
> I'm new to data warehousing and have started reading "The Data Warehouse
> Lifecycle Toolkit" by Kimbal (and others). From it I understood that the
> database in your application (normalised) is very differenent to the one
in
> your warehouse (denormalised). But from reading about SQL Server analysis
> server it does n't seem to matter what you use as your source as you can
> create your cubes from an application database design.
> Is this right? are there any drawbacks to this. It would mean that we
won't
> need another table design for our warehouse database.
> Thanks,
> --
> Nuala
|||Quoting JT in microsoft.public.sqlserver.datawarehouse:

>So the idea of data warehousing is that you perform your analysis against
>summarized and highly indexed data instead of at the transactional level.
Recommended reading (since I've just read it... )
"The impact of alternative diagrams on the accuracy of recall:
A comparison of star-schema diagrams and entity-relationship diagrams"
Corral et al., ' www.sciencedirect.com ' .
All that we see, or seem,
is but a dream, within a dream,
installed by the Machine

Database Design - newbie question

Hi ,
First of all my apologies for this very basic question but I can n't find a
definite answers to this question.
I'm new to data warehousing and have started reading "The Data Warehouse
Lifecycle Toolkit" by Kimbal (and others). From it I understood that the
database in your application (normalised) is very differenent to the one in
your warehouse (denormalised). But from reading about SQL Server analysis
server it does n't seem to matter what you use as your source as you can
create your cubes from an application database design.
Is this right? are there any drawbacks to this. It would mean that we won't
need another table design for our warehouse database.
Thanks,
NualaWhat differentiates the data warehouse design from the online transactional
database is the following:
1. To optimize the OLTP database, historical records are often migrated
to the warehouse, and it is from here that trend reports / analysis are
generated. Also, the indexing on the warehouse is optimized for analysis
purposes. The warehouse typically has much more indexing.
2. The warehouse databases are typically located on a different server
that is used exclusively for reporting and analysis. This reduces the load
on the OLTP server.
3. To improve the performace of analysis, data in the warehouse may be
stored in multiple levels of summarization, and most analysis may only be
derived from the smaller summarized datasets.
So the idea of data warehousing is that you perform your analysis against
summarized and highly indexed data instead of at the transactional level.
"Nuala" <nuala.cullen@.prnewswire.co.uk> wrote in message
news:BE655942-E657-46BF-AEAD-9A607AEEAB6F@.microsoft.com...
> Hi ,
> First of all my apologies for this very basic question but I can n't find
a
> definite answers to this question.
> I'm new to data warehousing and have started reading "The Data Warehouse
> Lifecycle Toolkit" by Kimbal (and others). From it I understood that the
> database in your application (normalised) is very differenent to the one
in
> your warehouse (denormalised). But from reading about SQL Server analysis
> server it does n't seem to matter what you use as your source as you can
> create your cubes from an application database design.
> Is this right? are there any drawbacks to this. It would mean that we
won't
> need another table design for our warehouse database.
> Thanks,
> --
> Nuala|||Quoting JT in microsoft.public.sqlserver.datawarehouse:

>So the idea of data warehousing is that you perform your analysis against
>summarized and highly indexed data instead of at the transactional level.
Recommended reading (since I've just read it... )
"The impact of alternative diagrams on the accuracy of recall:
A comparison of star-schema diagrams and entity-relationship diagrams"
Corral et al., ' www.sciencedirect.com ' .
All that we see, or seem,
is but a dream, within a dream,
installed by the Machine

Database Design

Hi,
I'm a newbie, how do i created a table for the survey data.
Given the questions for each user:
Do you Smoke ? Answer Yes
If Yes, How many times Answer 3
Do you take alcohol? Answer No
How will i create a table for this.
Do i do like this
UserName Do_You_Smoke How_Many_Times Alchohol
User1 yes 3 No
I want to create a report from this survey and Pull up the data for each
user on the form again for modification
Please Help
There are a lot of possible answers to this question. It really depends on
what your business needs are. I would assume you're going to want to change
the survey often, so you might want to consider something like this:
Question
======
QuestionKey
Question
BeginDate
EndDate
Answer (You might actually want to have several of these, depending on
complexity)
=====
AnswerKey
Answer
BeginDate
EndDate
QuestionAnswerMatrix (Match available answers where needed.)==============
QuestionKey
AnswerKey (AnswerKey could be blank for free text answers if you have those.)
BeginDate
EndDate
User
====
UserKey
UserName
etc, etc, etc
UserAnswers
=========
UserKey
QuestionAnswerKey
SurveyDate
This should at least give you some ideas. The most important thing in
database design is making sure the design is strong, normalized and yet meets
the needs of the business. If you haven't even asked the questions, there's
no way to design well. Based on the design above though, you should be able
to create stored procedures that easily report on and modify the data for the
surveys, as well as track historical survey "template" changes.
"Givosky" wrote:

> Hi,
> I'm a newbie, how do i created a table for the survey data.
> Given the questions for each user:
> Do you Smoke ? Answer Yes
> If Yes, How many times Answer 3
> Do you take alcohol? Answer No
> How will i create a table for this.
> Do i do like this
> UserName Do_You_Smoke How_Many_Times Alchohol
> User1 yes 3 No
> I want to create a report from this survey and Pull up the data for each
> user on the form again for modification
> Please Help
|||If your intention is actually to record information about each user then
something like this might be appropriate:
CREATE TABLE Users (username VARCHAR(30) NOT NULL, smokes_per_day INTEGER
NOT NULL CHECK (cigarettes_per_day>=0), alcohol_consumption INTEGER NOT NULL
.... etc)
I'm guessing that the Yes/No answers are redundant. They would just drive
the presentation in the GUI rather than be actual useful information (for
example cigarettes_per_day = 0 implies "I don't smoke"). On the other hand if
you need something more generic to handle many different types of survey you
might take a quite different approach.
David Portas
SQL Server MVP
|||Thanx for that useful information
"MeanOldDBA" wrote:
[vbcol=seagreen]
> There are a lot of possible answers to this question. It really depends on
> what your business needs are. I would assume you're going to want to change
> the survey often, so you might want to consider something like this:
> Question
> ======
> QuestionKey
> Question
> BeginDate
> EndDate
> Answer (You might actually want to have several of these, depending on
> complexity)
> =====
> AnswerKey
> Answer
> BeginDate
> EndDate
> QuestionAnswerMatrix (Match available answers where needed.)==============
> QuestionKey
> AnswerKey (AnswerKey could be blank for free text answers if you have those.)
> BeginDate
> EndDate
> User
> ====
> UserKey
> UserName
> etc, etc, etc
> UserAnswers
> =========
> UserKey
> QuestionAnswerKey
> SurveyDate
> This should at least give you some ideas. The most important thing in
> database design is making sure the design is strong, normalized and yet meets
> the needs of the business. If you haven't even asked the questions, there's
> no way to design well. Based on the design above though, you should be able
> to create stored procedures that easily report on and modify the data for the
> surveys, as well as track historical survey "template" changes.
>
> "Givosky" wrote: