From: BoyerG on
Norbert Winkler <norbert.winkler1(a)gmx.de> writes:

> Hi,
>
> for creating a unique index with a date-column A_DATE I'm using a
> calculated column X_DATE as (trunc(A_DATE)):
>
> CREATE UNIQUE INDEX UX_A_TABLE
> ON A_TABLE (
> ...,
> X_DATE
> )
> /

No. I guess you could create a table of dates, maybe call it day, and
then make its PK the date truncated. Pre-populate it with the days that
can happen, and then make your "day" columns children of that domain
set.

> Using A_DATE in UX_A_TABLE would fail if someone would use sysdate two
> times a day.
> Is there a column-data-type restricted to truncated date format?

Don't understand how having the datatype would solve this issue.

--
Galen Boyer

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Norbert Winkler on
Am Mon, 12 Apr 2010 06:31:35 -0700 (PDT) schrieb Ed Prochak:

> combined date/time type. There is no truncated date type. What's
> stopping you from using a check constraint?
>
OK, that's a possibility. But the calculated column seem me to be the
approach with the most benefit.

--
Norbert
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit
Production
From: Mark D Powell on
On Apr 12, 5:39 pm, joel garry <joel-ga...(a)home.com> wrote:
> On Apr 12, 1:57 pm, Robert Klemme <shortcut...(a)googlemail.com> wrote:
>
>
>
>
>
> > On 04/12/2010 04:54 PM, Mark D Powell wrote:
>
> > > On Apr 12, 6:22 am, Norbert Winkler <norbert.winkl...(a)gmx.de> wrote:
> > >> Hi,
>
> > >> for creating a unique index with a date-column A_DATE I'm using a
> > >> calculated column X_DATE as (trunc(A_DATE)):
>
> > >> CREATE UNIQUE INDEX UX_A_TABLE
> > >>   ON A_TABLE (
> > >>     ...,
> > >>     X_DATE
> > >>   )
> > >> /
>
> > >> Using A_DATE in UX_A_TABLE would fail if someone would use sysdate two
> > >> times a day.
> > >> Is there a column-data-type restricted to truncated date format?
>
> > > Normally indexes on date columns are non-unique
>
> > Err, doesn't that depend on the index definition?  I don't see any
> > general rule that would make indexes specifically on DATE columns non
> > unique.  Or did you mean that usually people define non unique indexes
> > on DATE columns?
>
> For one of my systems, and of course I haven't made sure that the
> requirement for date is met:
>
>   1  select uniqueness,count(*) from dba_indexes a,dba_ind_columns b
>   2  where a.index_name=b.index_name
>   3  and a.owner=b.index_owner
>   4  and b.column_name like '%_DATE%'
>   5* group by uniqueness
> SYS(a)TTST> /
>
> UNIQUENES   COUNT(*)
> --------- ----------
> NONUNIQUE         34
> UNIQUE           213
>
> I think I agree with where Mark is coming from, though, if he is
> assuming primary key v. other keys.  This system is kinda weird that
> way for an ERP/MRP.
>
>
>
> > > but if you want to
> > > restrict a user to only one entry per day then using trunc(sysdate)
> > > would result in a time of midnight.  All date columns always have a
> > > time component.  However I think you would need composite index on
> > > user and date if you want to perform this test per user.
>
> > What user?  Am I missing something from the original question?
>
> The original question was kind of ambiguous, perhaps Norbert could
> tell us what he is trying to do rather than how to do something
> mysterious.
>
> jg
> --
> @home.com is bogus.http://www.infoworld.com/print/119525- Hide quoted text -
>
> - Show quoted text -

My comment that most indexes on date columns are non-unique is in
reference to single column indexes which is what I believe Norbert was
asking about. In my experience it is rarely logical for single column
indexes on date data types to be unique even if if is possible.

Looking back at the sample code it appears that the index is probably
multi-column and so a unique index on trunc(sysdate) would limit the
table to one row per set of remaining key column values per day. Even
with update from Norbert I cannot tell if we answered his question
fully or not.

Mark D Powell