Function-Based index 
Author Message
 Function-Based index

I have a field in my "products" table called "Flags",
varchar(20) filled with 1 or 0, each character is a
representation of a flag status:

(I.e)
edpno        flags
-----        -----
122345       1100101011
987886       0100001001

Where:
  position 1 represents the Active status
  position 2 represents available inventory
  position 3 represents displayable flag
  etc,
  etc

We have created a function that returns the value for a
given position within the flags field; a query to that
table will look like this:

select edpno
  from products
 where dbo.GetFlags(flags,'Active') = 1
 and   dbo.GetFlags(flags,'AvailInv') = 1

Can I create an index based on this function?
Is this the right design to solve this issue? I can have
multiple flags being added later on, that's why we
designed like this instead of creating a field per flag.

Thanks,
JC



Mon, 24 Oct 2005 03:51:27 GMT
 Function-Based index

Seems kinda squirly. Even if you caould make an index like that, the index
would have to separate the flags out, when you could just have them separate
from the beginning.
Still, I'm an idiot, and i'm interested so , I 'll stay tuned.
That's my 2 cents worth, but i guess i still owe you two cents.
cu


Quote:
> I have a field in my "products" table called "Flags",
> varchar(20) filled with 1 or 0, each character is a
> representation of a flag status:

> (I.e)
> edpno        flags
> -----        -----
> 122345       1100101011
> 987886       0100001001

> Where:
>   position 1 represents the Active status
>   position 2 represents available inventory
>   position 3 represents displayable flag
>   etc,
>   etc

> We have created a function that returns the value for a
> given position within the flags field; a query to that
> table will look like this:

> select edpno
>   from products
>  where dbo.GetFlags(flags,'Active') = 1
>  and   dbo.GetFlags(flags,'AvailInv') = 1

> Can I create an index based on this function?
> Is this the right design to solve this issue? I can have
> multiple flags being added later on, that's why we
> designed like this instead of creating a field per flag.

> Thanks,
> JC



Mon, 24 Oct 2005 04:14:34 GMT
 Function-Based index

Quote:
> I have a field in my "products" table called "Flags",
> varchar(20) filled with 1 or 0, each character is a
> representation of a flag status:

> (I.e)
> edpno        flags
> -----        -----
> 122345       1100101011
> 987886       0100001001

> Where:
>   position 1 represents the Active status
>   position 2 represents available inventory
>   position 3 represents displayable flag
>   etc,
>   etc

SQLServer does not have function-based indexes, although it does have
indexed views.

In SQLServer you could use the BIT datatype and break each flag out into a
seperate column.  Bit columns will be packed together for storage.  You
could also keep your flags column and syncronize the flags column and the
broken-out bit columns in a trigger.

Anyway the BIT columns can be used in an index, although indexes on bit
columns are rarely very usefull because they usually have poor selectivity.

David



Mon, 24 Oct 2005 04:29:41 GMT
 Function-Based index
Quote:
>> I have a field in my "products" table called "Flags",

varchar(20) filled with 1 or 0, each character is a
representation of a flag status: <<

You are imitating an assembly language program in SQL!! Your UDF will
only slow the processing down to a row-at-a-time file system crawl.

Please, please, please read a book on data modeling before you destroy
your employer.  What you are doing is not just wrong, it is SOOOO wrong.
And there is no way in hell anyone can give an RDBMS course in emails.
Stop what you are doing and get help.  

--CELKO--
 ===========================
 Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in your
schema are.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Mon, 24 Oct 2005 04:31:00 GMT
 Function-Based index
Bit masking is a bad design scheme. Though not very pronounced, it
fundamentally violates 1NF and thus some inherent defects of a table that is
not normalized, exists here too.

In T-SQL, you can use a table valued UDF to parse the flag value to
individual bits & use them in your comparison. Something along the lines of
:


RETURNS TABLE
AS

              Number AS "pos"
         FROM Numbers

-- Where Numbers is a table with sequentially incrementing numbers.
-- Search this newsgroup and you'll find tricks to create one.

The correct way to design is to decompose the information bundled up as
"flag" into another table with a relationship table (if needed) which can
identify each "bit" information.

CREATE TABLE Status (
     Status_Id CHAR(1) NOT NULL PRIMARY KEY,
     Descr VARCHAR(20) NOT NULL)

CREATE TABLE Inventory_Status (
     EdpNo INT NOT NULL,
     Status_Id NOT NULL
          REFERENCES Status(Status_Id)
              ON UPDATE CASCADE
              ON DELETE CASCADE,
     PRIMARY KEY (EdpNo, Status_Id))

If there are only a few statuses, you can also use a CHECK constraint
instead of a referencing the Status table. However, this may not be always
recommended since you will be forced to maintain this information in your
data dictionary.

--
- Anith
( Please reply to newsgroups only )



Mon, 24 Oct 2005 04:35:37 GMT
 Function-Based index


Quote:
> Bit masking is a bad design scheme. Though not very pronounced, it
> fundamentally violates 1NF and thus some inherent defects of a table that
is
> not normalized, exists here too.

> In T-SQL, you can use a table valued UDF to parse the flag value to
> individual bits & use them in your comparison. Something along the lines
of
> :


> RETURNS TABLE
> AS

>               Number AS "pos"
>          FROM Numbers

> -- Where Numbers is a table with sequentially incrementing numbers.
> -- Search this newsgroup and you'll find tricks to create one.

> The correct way to design is to decompose the information bundled up as
> "flag" into another table with a relationship table (if needed) which can
> identify each "bit" information.

> CREATE TABLE Status (
>      Status_Id CHAR(1) NOT NULL PRIMARY KEY,
>      Descr VARCHAR(20) NOT NULL)

> CREATE TABLE Inventory_Status (
>      EdpNo INT NOT NULL,
>      Status_Id NOT NULL
>           REFERENCES Status(Status_Id)
>               ON UPDATE CASCADE
>               ON DELETE CASCADE,
>      PRIMARY KEY (EdpNo, Status_Id))

That is a horrible design.  Just break the flags into individual columns.
There is no reason to "uncrosstab" this information.

You are unnecesarilly demoting metadata to mere data.  That is a horrible
violation of good relational design: at least as bad as using a flags field.
Plus it performs very very poorly.

Followed to it's extreme, all tables would just have ID, FieldName,
FieldValue columns.
It's the promotion of an attribute to an entity, and while sometimes
necessary, it is best avoided.

David



Mon, 24 Oct 2005 04:55:55 GMT
 Function-Based index

Quote:
>> There is no reason to "uncrosstab" this information. <<

If you feel it helps, please refer to:
http://www.pgro.uk7.net/perform_0119.htm

Quote:
>> It's the promotion of an attribute to an entity, and while sometimes

necessary, it is best avoided. <<

Where is this idea of 'promotion' coming from? And also what is 'demoting'
metadata? If possible, please read the article on the Orthogonal design
principle by Date in the book Relational Database Writing 1991-94. Simply
voicing opinions about a design being 'horrible' is easy. Proving it on
logical grounds based on sound understanding is hard!

--
- Anith
( Please reply to newsgroups only )



Mon, 24 Oct 2005 05:18:23 GMT
 Function-Based index
Anith,

  I would offer that there is a very big difference between the model
described in the link below and the one here.  In the link below, each
position of the bit string identifies the presence or absence of a
permission
for the user.  A permission is pretty clearly an entity that has a specified
set of values, and a particular permission is pretty clearly an attribute of
a person.  "Permissions" (plural) is not "an" (singular) attribute of a
person,
so it makes sense to normalize the example given there.

  But just because some information can fit into a bitmap doesn't
mean that information is a set of values for a single entity.  It does make
the question harder, because attributes with only Yes and No as possible
values look like they could be representing whether separate values of
some common entity are associated to something.

But here we have something completely different.  There is no clear
entity with values that encompass

active status
displayable
available inventory

and so on.  These are not possible values of a single attribute, unless your
attribute is "attribute".  You've called this attribute [status], but I
think that's
a very big stretch.  It might work for form components with values active,
hidden, selected, and so on, which are clearly attributes a control either
has or doesn't have, but it doesn't work for the ones here, which are not
the repeated kinds of things 1NF prohibits.  The original poster said there
were more.  Maybe there will be other product attributes like

Discontinued
Ground Ship only
Perishable
New

Putting these into a [status] or [generic attribute] table is as David said,
demoting metadata to data.  Design errors of the reverse kind are
more common, but neither is good.  And by collecting these disparate
attributes and putting them in one table, you are creating an entity from
something that doesn't exist in the real model.

I think what you're suggesting is far too much in the OO direction, and
is like taking Northwind..Orders and creating a table called
OrderAttributes that holds (OrderID, AttributeID, AttributeValue) with
rows like (11000, 4, 2)
-- maybe 4 is the ShipVia attribute ID, and ShipVia = 2 for that
order.

I think Date is worth reading, but not without a grain of salt close
at hand.  There are simply too many issues of this kind he fails to
address.

Steve Kass
Drew University

Quote:

>>>There is no reason to "uncrosstab" this information. <<

>If you feel it helps, please refer to:
>http://www.pgro.uk7.net/perform_0119.htm

>>>It's the promotion of an attribute to an entity, and while sometimes

>necessary, it is best avoided. <<

>Where is this idea of 'promotion' coming from? And also what is 'demoting'
>metadata? If possible, please read the article on the Orthogonal design
>principle by Date in the book Relational Database Writing 1991-94. Simply
>voicing opinions about a design being 'horrible' is easy. Proving it on
>logical grounds based on sound understanding is hard!

>--
>- Anith
>( Please reply to newsgroups only )



Mon, 24 Oct 2005 07:08:20 GMT
 Function-Based index
JC,

  The really nice way to solve this would be with bitmap indexes
(which are not really indexes at all).  Unfortunately, SQL Server
doesn't support them, and unless the set of edpno values is modest
in number and relatively static, I'm not sure trying to implement them
would be worth trying.  Here's at least some code to show what the
idea is all about.  While I don't give an example (because OR-ing and
AND-ing long binary values is not an option in T-SQL), the real
power in (real) bitmap indexes is to be able to find all items with a
certain combination of flags set.

create table Seq64000 (
  N    int not null,
  byte smallint not null,
  mask binary(1)
)
insert into Seq64000
select N+1, 1+N/8, substring(cast(power(2,N%8) as binary(2)),2,1)
from (
  select ProductID*830 + OrderID - 10248 - 830 as N
  from Northwind..Orders, Northwind..Products
  where ProductID*830 + OrderID - 10248 - 830 <= 64000
) N
go

alter table Seq64000
add constraint pk_Seq64000 primary key (N)
go

create table edp (
  edpNo   int not null primary key,
  edpName varchar(20)
)
go

insert into edp
select (
  select min(OrderID)
  from Northwind..Orders O
  where O.CustomerID = C.CustomerID
), CustomerID
from Northwind..Customers C
where exists (
  select *
  from Northwind..Orders O
  where O.CustomerID = C.CustomerID
)
go

create table edpAttributes (
  attrib   varchar(30),
  bitmap   binary(8000) not null default 0x00
)
go

insert into edpAttributes (attrib) values ('Active')
insert into edpAttributes (attrib) values ('Available Inventory')
insert into edpAttributes (attrib) values ('Displayable')
go

create view edp_att as
select
  N as edpNo, attrib
from edpAttributes, Seq64000
where cast(mask as int) & substring(bitmap,byte,1) <> 0
go

create trigger edp_att_insert
on edp_att instead of insert as
declare C cursor
for
  select edpNo, attrib from inserted


open C





  update edpAttributes set

           + cast(

               as binary(1))



end
close C
deallocate C
go

-- All is not as obvious as it seems with how edp_att works!!
insert into edp_att values (11011, 'Active')
insert into edp_att values (11011, 'Available Inventory')
insert into edp_att values (11011, 'Displayable')
insert into edp_att values (11014, 'Active')
insert into edp_att values (11014, 'Available Inventory')
insert into edp_att values (11019, 'Active')
go

select * from edp_att
go

drop table edpAttributes, edp, Seq64000
drop view edp_att

Steve Kass
Drew University

Quote:

>I have a field in my "products" table called "Flags",
>varchar(20) filled with 1 or 0, each character is a
>representation of a flag status:

>(I.e)
>edpno        flags
>-----        -----
>122345       1100101011
>987886       0100001001

>Where:
>  position 1 represents the Active status
>  position 2 represents available inventory
>  position 3 represents displayable flag
>  etc,
>  etc

>We have created a function that returns the value for a
>given position within the flags field; a query to that
>table will look like this:

>select edpno
>  from products
> where dbo.GetFlags(flags,'Active') = 1
> and   dbo.GetFlags(flags,'AvailInv') = 1

>Can I create an index based on this function?
>Is this the right design to solve this issue? I can have
>multiple flags being added later on, that's why we
>designed like this instead of creating a field per flag.

>Thanks,
>JC



Mon, 24 Oct 2005 07:52:25 GMT
 Function-Based index
Steve,

I can see the difference between the scenarios described in the link I
posted and the problem which JC have. However the requirement for 1NF is
still the same in both cases. And among the other reasons mentioned, the
inability to implement referential integrity stands as a problem with the
scheme you propose. And having multiple attributes with values Yes/No or
True/False simply makes it a different case. Purely from the relational
perspective, keeping SQL aside these attributes, if draw their values from a
single domain, the table must be normalized.

Quote:
>> These are not possible values of a single attribute, unless your

attribute is "attribute". <<

That is possible. Now, that requires a more thorough inspection of the
business model. One possibility is that, all these attributes may not have
values with 2VL. And, more importantly, it is also possible that attributes
like Discontinued, Perishable, New etc are attributes with different
business meanings and thus cannot draw their values from the same set of
values (domains) and thus will form different attributes for the entity.

Quote:
>> Putting these into a [status] or [generic attribute] table is as David

said, demoting metadata to data. <<

Again, this is not always true, unless you can prove that the attribute
values have different business meanings. And, can you post a reference,
where I can read about 'demoting' and 'promoting' metadata? An attribute is
identified by the value and the domain/type from where the values are being
drawn and the relation header that represent the attribute comprises of the
attribute name and the domain/type name from where the attributes draw their
values. Metadata, as I understand, has nothing to do with it.

Quote:
>> I think Date is worth reading, but not without a grain of salt close at

hand.  There are simply too many issues of this kind he fails to address.<<

Maybe yes, maybe not. The main reason for this 1NF confusion arises from the
inability of SQL to define and handle relational Domains. Had there been a
domain defined in JC's case such confusion would not have risen. It would be
very clear to the designer to know if there is only one set of statuses or
more. My response to JC, is based on the assumption that each bit of the
flag value will belong to the same domain (or perceived to be picked from a
single set of values which denotes different possible statuses)

--
- Anith
( Please reply to newsgroups only )



Mon, 24 Oct 2005 22:22:23 GMT
 Function-Based index
Anith,

  Am I misreading your comments, or are you actually suggesting
that when two columns of a table share a single domain of values, that
the table is not 1NF and must be normalized?  That would not make
sense to me.  It would mean a table could never have two columns
that draw their values from datetime, or two from char(1), or two from
{'Y','N'}.

  Other things to think about are whether or not any of the attributes
needs to allow a status of UNKNOWN, or will ever be marked as
PROPOSED, or another new value (although I will admit this
takes us into dangerous waters, especially with UNKNOWN).

  Finally, can you give a specific example of the kind of referential
integrity that might need to be maintained?  I am not proposing leaving
the bitmap, but am proposing keeping the separate columns in the
same table.  What referential integrity is impossible here that is
possible in the two-table (object-oriented, in my view) design?

SK

Quote:

>Steve,

>I can see the difference between the scenarios described in the link I
>posted and the problem which JC have. However the requirement for 1NF is
>still the same in both cases. And among the other reasons mentioned, the
>inability to implement referential integrity stands as a problem with the
>scheme you propose. And having multiple attributes with values Yes/No or
>True/False simply makes it a different case. Purely from the relational
>perspective, keeping SQL aside these attributes, if draw their values from a
>single domain, the table must be normalized.

>>>These are not possible values of a single attribute, unless your

>attribute is "attribute". <<

>That is possible. Now, that requires a more thorough inspection of the
>business model. One possibility is that, all these attributes may not have
>values with 2VL. And, more importantly, it is also possible that attributes
>like Discontinued, Perishable, New etc are attributes with different
>business meanings and thus cannot draw their values from the same set of
>values (domains) and thus will form different attributes for the entity.

>>>Putting these into a [status] or [generic attribute] table is as David

>said, demoting metadata to data. <<

>Again, this is not always true, unless you can prove that the attribute
>values have different business meanings. And, can you post a reference,
>where I can read about 'demoting' and 'promoting' metadata? An attribute is
>identified by the value and the domain/type from where the values are being
>drawn and the relation header that represent the attribute comprises of the
>attribute name and the domain/type name from where the attributes draw their
>values. Metadata, as I understand, has nothing to do with it.

>>>I think Date is worth reading, but not without a grain of salt close at

>hand.  There are simply too many issues of this kind he fails to address.<<

>Maybe yes, maybe not. The main reason for this 1NF confusion arises from the
>inability of SQL to define and handle relational Domains. Had there been a
>domain defined in JC's case such confusion would not have risen. It would be
>very clear to the designer to know if there is only one set of statuses or
>more. My response to JC, is based on the assumption that each bit of the
>flag value will belong to the same domain (or perceived to be picked from a
>single set of values which denotes different possible statuses)

>--
>- Anith
>( Please reply to newsgroups only )



Mon, 24 Oct 2005 22:35:54 GMT
 Function-Based index
Steve,

I may not have explained myself correctly. SQL tables will and must have
multiple columns with same data type because all you have is just 8 base
data types, I think. However, I was referring to the possible domains which
define the values for the statuses. The issue is whether there is one status
(or 'status type' for clarity) with one set of values or multiple 'status
types', each with its own set of values.

Let us assume a person entity has some attributes name, eye color, skin
color and hair color. As you can see the last three attributes can draw the
values, say from a domain of colors and the attribute name encodes the
business meaning for the values. However on close examination, you can see
that certain values say blue, which is applicable to eye color is not
applicable to hair color). Thus, the options for the designer are:

1. Apply column constraints based on the acceptable domain values for each
column.
2. Define a different domain for each of the attribute

Here color is not an entity related attribute however, the eye color, hair
color and skin color defines the attributes. Since there is no difference in
the business meaning in color, the above can be valid solutions since color
qualifies the attribute (note, eye color determines the person, not the
color) and not the entity.

However consider another case where a person entity along with name has some
other set of attributes which can be considered Boolean responses, say
smoker, drinker, drug {*filter*} etc. Since each of these predefined attributes
qualify the entity directly, the entity instead of :

Person (name, smoker, drinker, {*filter*}...)

can be normalized as :

Person (name, habit, response)

Since all the habits pertains to the Person. Now in the first example, can't
you normalize further to Person (name, organ, color)? Possibly yes, if there
are domains which can define the possible values for organ as well as color.
This solely depends upon the business requirements and the available
domains. If the business does not expose a domain called organ, then you
cannot possibly implement this.

Does this make it clear? If not, I am trying to find out an article by Hugh
Darwen on 1NF & I can post the reference if you like.

Quote:
>> I am not proposing leaving the bitmap, but am proposing keeping the

separate columns in the same table. <<

Does that make much of a difference? A set of values representing different
business attributes as a single column or multiple columns in the same row
are still the same. In SQL, you can have a table with concatenated values as
a single column and simply apply a view which can expose the values as
individual columns. Due to logical data independence, the view must behave
exactly like the table. From the design perspective both are not normalized,
assuming each bit in the flag value represent different values for a single
'status type'. It is anybody's guess which set of bits denotes which
statuses. Until you analyze and define the different 'status types' and its
values, one can argue either design is valid & I based by response based on
the perception that there is only one 'status type'.

--
- Anith
( Please reply to newsgroups only )



Mon, 24 Oct 2005 23:47:25 GMT
 Function-Based index
Anith,

  I think you and are are talking about different issues.
I agree that it is possible to "normalize" by replacing several
columns with the same domain by a separate table.

  But it sounds to me like you are saying that _whenever_ there
exist several columns with the same domain, that you are
immediately violating 1NF and _must_ "normalize." I disagree
with that.  Again, you are using an example where there is
a clear entity (in this case "habit"), with a well-defined domain
{tobacco, {*filter*}, {*filter*}, ...}

  In the example of this thread, however, there is not a clear
entity with a well-defined domain.  Just because all the attributes
in the example of this thread have domain {yes,no} does not
make them instances of a single entity.  Just because the shoe
fits doesn't mean you should wear it.

  Am I correct that you are recommending "normalization" whenever
there is more than one column with the same domain?  If not, what
is your criteria for deciding when to do so and when not to?

Steve

Quote:

>Steve,

>I may not have explained myself correctly. SQL tables will and must have
>multiple columns with same data type because all you have is just 8 base
>data types, I think. However, I was referring to the possible domains which
>define the values for the statuses. The issue is whether there is one status
>(or 'status type' for clarity) with one set of values or multiple 'status
>types', each with its own set of values.

>Let us assume a person entity has some attributes name, eye color, skin
>color and hair color. As you can see the last three attributes can draw the
>values, say from a domain of colors and the attribute name encodes the
>business meaning for the values. However on close examination, you can see
>that certain values say blue, which is applicable to eye color is not
>applicable to hair color). Thus, the options for the designer are:

>1. Apply column constraints based on the acceptable domain values for each
>column.
>2. Define a different domain for each of the attribute

>Here color is not an entity related attribute however, the eye color, hair
>color and skin color defines the attributes. Since there is no difference in
>the business meaning in color, the above can be valid solutions since color
>qualifies the attribute (note, eye color determines the person, not the
>color) and not the entity.

>However consider another case where a person entity along with name has some
>other set of attributes which can be considered Boolean responses, say
>smoker, drinker, drug {*filter*} etc. Since each of these predefined attributes
>qualify the entity directly, the entity instead of :

>Person (name, smoker, drinker, {*filter*}...)

>can be normalized as :

>Person (name, habit, response)

>Since all the habits pertains to the Person. Now in the first example, can't
>you normalize further to Person (name, organ, color)? Possibly yes, if there
>are domains which can define the possible values for organ as well as color.
>This solely depends upon the business requirements and the available
>domains. If the business does not expose a domain called organ, then you
>cannot possibly implement this.

>Does this make it clear? If not, I am trying to find out an article by Hugh
>Darwen on 1NF & I can post the reference if you like.

>>>I am not proposing leaving the bitmap, but am proposing keeping the

>separate columns in the same table. <<

>Does that make much of a difference? A set of values representing different
>business attributes as a single column or multiple columns in the same row
>are still the same. In SQL, you can have a table with concatenated values as
>a single column and simply apply a view which can expose the values as
>individual columns. Due to logical data independence, the view must behave
>exactly like the table. From the design perspective both are not normalized,
>assuming each bit in the flag value represent different values for a single
>'status type'. It is anybody's guess which set of bits denotes which
>statuses. Until you analyze and define the different 'status types' and its
>values, one can argue either design is valid & I based by response based on
>the perception that there is only one 'status type'.

>--
>- Anith
>( Please reply to newsgroups only )



Tue, 25 Oct 2005 00:33:46 GMT
 Function-Based index


. . .

Quote:
> However consider another case where a person entity along with name has
some
> other set of attributes which can be considered Boolean responses, say
> smoker, drinker, drug {*filter*} etc. Since each of these predefined
attributes
> qualify the entity directly, the entity instead of :

> Person (name, smoker, drinker, {*filter*}...)

> can be normalized as :

> Person (name, habit, response)
 ....
>From the design perspective both are not normalized,

Good.  Very clear.  This is the issue, precisely.

Are you suggesting that design

 Person (name, smoker, drinker, {*filter*}...)

Is somehow not normalized?  If so what normal form do you believe it fails
to achieve?

I think there is no issue of normalization here.
There is no difference in the level of normalization of these two designs.
One is just more general than the other.  The more general structure may be
required in certian situations, but has serious performance and design
drawbacks.

The more general design should be reserved for situations where the
flexibility it provides is requred.  Only if you cannot decide at
design-time what attributes might be recorded for a Person entity should you
use the more general structure.

David



Tue, 25 Oct 2005 00:47:12 GMT
 Function-Based index
Steve,

I see your point now. In JC's question, 'Active status' can be a very
different from 'available' and so is 'displayable' all belonging to distinct
domains. You are correct, just because they are all {1, 0}, does not mean
they belong to the same domain. These, at least by the name, may not seem to
be different values for a single status which defines a single business
meaning. My initial response, was based on the assumption that all these may
belong to the same pool of values & could be possibly wrong. However, as a
general rule, this distinction is defined by the business model.

--
- Anith
( Please reply to newsgroups only )



Tue, 25 Oct 2005 01:33:27 GMT
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Function based indexes and index fast full scan

2. ORA-01031 with Create Index for a Function Based Index

3. function-based index

4. Function-Based Index

5. Function-based Index

6. Function-based indexes and histograms

7. Inability to use function-based indexes at times

8. Function based index

9. Can a Function-Based Index do this?

10. Function Based Indexes and ODBC - Help!?

11. can't create function-based index

12. Oracle 8i and function-based indexes


 
Powered by phpBB® Forum Software