Re: Proper database design for best performance?

That is a great idea. Now I need to figure out how I should set up some type of data integrety check since I'm allowing nulls in this column.

Thanks

In article <952035101.24230.0.pluto.d4ee154e_at_news.demon.nl>,   "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote:
> Use char(1) containing NULL for processed rows and anything for
> non-processed rows. If all is well, NULL still won't be go into the
index,
> so the index will be very small.
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>
> <jbrychka_at_my-deja.com> wrote in message news:89mg61$132
$1_at_nnrp1.deja.com...
> > I would like some ideas on the best way to set up data for fast
access.
> >
> > I have a very large table that I look up for records that have not
been
> > processed. The query would look something like this:
> >
> > select column_a
> > from table
> > where date_column is NULL
> >
> > This type of query cannot use an index so it is very slow. To get
> > around the index issue I was thinking of defaulting this
date_column to
> > a specific date that I would then put in my query. Something like
this:
> >
> > select column_a
> > from table
> > where date_column = :default_date
> >
> > This way I could use an index. The only thing I don't like about
this
> > is that I am putting this bogus date value in the column.
> >
> > Another option is to add an indicator column that would default
to "N"
> > for new records and then get updated to "Y" when processed. The
issue
> > I have with this is that I still need the date column to know when
it
> > is processed so now I have two columns instead of just one which
causes
> > the table to use more table space.
> >
> > If anybody has any opinion on this or other alternatives, I would
like
> > to hear about it.
> >
> > Thanks,
> >
> > Jim
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Mar 03 2000 - 13:32:35 CST