Relational Database

Hi,
I have a very simple question.
In what cases are relational databases necessary?
Are they really necessary in cases where only a
single type of query is to be performed based on one unique
field or can we just put all fields together in a single database
and just access them through that unique field?Shwetabh (shwetabhgoel@.gmail.com) writes:
> I have a very simple question.
> In what cases are relational databases necessary?
> Are they really necessary in cases where only a
> single type of query is to be performed based on one unique
> field or can we just put all fields together in a single database
> and just access them through that unique field?

There are plenty of alternatievs to relational databases. There are object-
oriented databases, there are probably still some hierarchical databases
around, and there are systems that uses flat files.

But the relational databases dominate the market, probably because they
have proven to be very good at handling large amounts of data.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland Sommarskog wrote:
> Shwetabh (shwetabhgoel@.gmail.com) writes:
> > I have a very simple question.
> > In what cases are relational databases necessary?
> > Are they really necessary in cases where only a
> > single type of query is to be performed based on one unique
> > field or can we just put all fields together in a single database
> > and just access them through that unique field?
> There are plenty of alternatievs to relational databases. There are object-
> oriented databases, there are probably still some hierarchical databases
> around, and there are systems that uses flat files.
> But the relational databases dominate the market, probably because they
> have proven to be very good at handling large amounts of data.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx

Actually I am not asking about the alternatives. I just want to know
that are
relational databases really necessary for me if I require just a single
record
every time with no changes in structure, i.e I always need a record
based on
a unique value. Do i still need to create relations in the database or
am I better off
butting all fields in a single table and getting data from there.|||"Shwetabh" <shwetabhgoel@.gmail.com> wrote in message
news:1140086144.048226.309750@.g14g2000cwa.googlegr oups.com...
> Actually I am not asking about the alternatives. I just want to know
> that are
> relational databases really necessary for me if I require just a single
> record
> every time with no changes in structure, i.e I always need a record
> based on
> a unique value. Do i still need to create relations in the database or
> am I better off
> butting all fields in a single table and getting data from there.

More accurately, it sounds like you're asking whether you need to normalize
your database.

In this case probably not and using something like SQL Server may be
overkill. But without knowing more details, I don't think any of us can say
for sure.
|||Shwetabh wrote:
> Actually I am not asking about the alternatives. I just want to know
> that are
> relational databases really necessary for me if I require just a single
> record
> every time with no changes in structure, i.e I always need a record
> based on
> a unique value. Do i still need to create relations in the database or
> am I better off
> butting all fields in a single table and getting data from there.

I don't think you asked the right question. It seems you aren't asking
whether to use relational database systems but whether to normalize
your database or not.

The main motivation to normalize data is to preserve its integrity when
it is updated. A secondary reason is that normalization can help
performance by ensuring you aren't maintaining redundant data. Given
those factors you ought to have a good excuse if you don't normalize.

--
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/...US,SQL.90).aspx
--|||>> if I require just a single record every time with no changes in structure, i.e I always need a record based on a unique value. <<

There is nothing wrong with an indexed file, which is probably
supported by your host language. RDBMS is for large amounts of
inter-related data where integrity and portability are the big issue.|||It depends what you are doing.

If its a single row ever then just store the information in a xml document
on the file system.

If you are storing multiple rows then I'd consider using a database system
because you then dont have to roll your own data access code, having said
that, .NET has a number of facilities to help you there.

Tony.

--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials

"Shwetabh" <shwetabhgoel@.gmail.com> wrote in message
news:1140086144.048226.309750@.g14g2000cwa.googlegr oups.com...
> Erland Sommarskog wrote:
>> Shwetabh (shwetabhgoel@.gmail.com) writes:
>> > I have a very simple question.
>> > In what cases are relational databases necessary?
>> > Are they really necessary in cases where only a
>> > single type of query is to be performed based on one unique
>> > field or can we just put all fields together in a single database
>> > and just access them through that unique field?
>>
>> There are plenty of alternatievs to relational databases. There are
>> object-
>> oriented databases, there are probably still some hierarchical databases
>> around, and there are systems that uses flat files.
>>
>> But the relational databases dominate the market, probably because they
>> have proven to be very good at handling large amounts of data.
>>
>> --
>> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>>
>> Books Online for SQL Server 2005 at
>> http://www.microsoft.com/technet/pr...oads/books.mspx
>> Books Online for SQL Server 2000 at
>> http://www.microsoft.com/sql/prodin...ions/books.mspx
> Actually I am not asking about the alternatives. I just want to know
> that are
> relational databases really necessary for me if I require just a single
> record
> every time with no changes in structure, i.e I always need a record
> based on
> a unique value. Do i still need to create relations in the database or
> am I better off
> butting all fields in a single table and getting data from there.sql

re-indexing "sliding window" partitioned tables - is it necessary?

Hello
We have a partitioning strategy in place where we keep 10 days worth of data
each on its own day partition and a weekly sliding window where we remove old
days and add new days.
These tables only experience INSERTS (Bulk inserts and BCP), no updates or
deletes and our clustered index is also partitioned.
I would like to know if it is necessary to ever check for fragmentation or
re-index this table. My thinking is that it is not as all INSERTS will be
contigiuous.
thanks
--
-- cranfield, DBA> I would like to know if it is necessary to ever check for fragmentation or
> re-index this table. My thinking is that it is not as all INSERTS will be
> contigiuous.
It is likely you have at least some fragmentation unless you load data in
index key order of all indexes. You might consider including an ALTER INDEX
REBUILD or REORGANIZE of the last loaded partition as part of your daily
sliding window maintenance. If you SWITCH a fully loaded table into the
partitioned table, you can reorg before switching in.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:89CC380F-46B3-4E0B-927A-4552627BF667@.microsoft.com...
> Hello
> We have a partitioning strategy in place where we keep 10 days worth of
> data
> each on its own day partition and a weekly sliding window where we remove
> old
> days and add new days.
> These tables only experience INSERTS (Bulk inserts and BCP), no updates or
> deletes and our clustered index is also partitioned.
> I would like to know if it is necessary to ever check for fragmentation or
> re-index this table. My thinking is that it is not as all INSERTS will be
> contigiuous.
> thanks
> --
> -- cranfield, DBA|||Hi Dan
Yes, that makes sense. Our partitioned table gets loaded intra-businessday
and we the window gets moved only once a week on the weekend. We have 7 days
of future partitions always defined. So would you suggest a fragmentation
check at the end of each business day and then a rebuild of the entire index
should there be excessive fragmentation? Our maintenance window is very
small and these partitioned tables have approx 1 mill rows/day.
--
-- cranfield, DBA
"Dan Guzman" wrote:
> > I would like to know if it is necessary to ever check for fragmentation or
> > re-index this table. My thinking is that it is not as all INSERTS will be
> > contigiuous.
> It is likely you have at least some fragmentation unless you load data in
> index key order of all indexes. You might consider including an ALTER INDEX
> REBUILD or REORGANIZE of the last loaded partition as part of your daily
> sliding window maintenance. If you SWITCH a fully loaded table into the
> partitioned table, you can reorg before switching in.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:89CC380F-46B3-4E0B-927A-4552627BF667@.microsoft.com...
> > Hello
> >
> > We have a partitioning strategy in place where we keep 10 days worth of
> > data
> > each on its own day partition and a weekly sliding window where we remove
> > old
> > days and add new days.
> >
> > These tables only experience INSERTS (Bulk inserts and BCP), no updates or
> > deletes and our clustered index is also partitioned.
> >
> > I would like to know if it is necessary to ever check for fragmentation or
> > re-index this table. My thinking is that it is not as all INSERTS will be
> > contigiuous.
> >
> > thanks
> > --
> > -- cranfield, DBA
>|||> So would you suggest a fragmentation
> check at the end of each business day and then a rebuild of the entire
> index
> should there be excessive fragmentation? Our maintenance window is very
> small and these partitioned tables have approx 1 mill rows/day.
Assuming your indexes are aligned, you might consider an unconditional
REBUILD or REORGANIZE of only the last loaded partition since I expect
you'll have about the same level of fragmentation of the newly loaded
partition every day. If you don't have a large enough maintenance window to
REBUILD, you can still REORGANIZE online to reduce fragmentation.
Hope this helps.
Dan Guzman
SQL Server MVP
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:8F5B6484-731A-4B99-8EAC-EBD811B42854@.microsoft.com...
> Hi Dan
> Yes, that makes sense. Our partitioned table gets loaded intra-businessday
> and we the window gets moved only once a week on the weekend. We have 7
> days
> of future partitions always defined. So would you suggest a fragmentation
> check at the end of each business day and then a rebuild of the entire
> index
> should there be excessive fragmentation? Our maintenance window is very
> small and these partitioned tables have approx 1 mill rows/day.
> --
> -- cranfield, DBA
>
> "Dan Guzman" wrote:
>> > I would like to know if it is necessary to ever check for fragmentation
>> > or
>> > re-index this table. My thinking is that it is not as all INSERTS will
>> > be
>> > contigiuous.
>> It is likely you have at least some fragmentation unless you load data in
>> index key order of all indexes. You might consider including an ALTER
>> INDEX
>> REBUILD or REORGANIZE of the last loaded partition as part of your daily
>> sliding window maintenance. If you SWITCH a fully loaded table into the
>> partitioned table, you can reorg before switching in.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
>> news:89CC380F-46B3-4E0B-927A-4552627BF667@.microsoft.com...
>> > Hello
>> >
>> > We have a partitioning strategy in place where we keep 10 days worth of
>> > data
>> > each on its own day partition and a weekly sliding window where we
>> > remove
>> > old
>> > days and add new days.
>> >
>> > These tables only experience INSERTS (Bulk inserts and BCP), no updates
>> > or
>> > deletes and our clustered index is also partitioned.
>> >
>> > I would like to know if it is necessary to ever check for fragmentation
>> > or
>> > re-index this table. My thinking is that it is not as all INSERTS will
>> > be
>> > contigiuous.
>> >
>> > thanks
>> > --
>> > -- cranfield, DBA