2 more cents:
One positive side affect of this solution is that you will later
be able to add other types of indexes, like spatial indexes, etc.
I think it's important to keep the design as open and extensible
as possible. Also a great way to postpone things and release a
preview faster .

Regards,
Michael

Michael Baytalsky wrote:
>
>> Would you consider the removal of the index statistics, and the
>> subsequent removal of the ability for ElevateDB to provide option 1)
>> above significantly negative ?
> IMO, Yes.
>
> I think it would be best if it is made as an option for a particular
> index if someone needs to update a huge table in the described manner.
> This way my suggestion is: do not remove the statistics at first.
> Create a separate implementation of different type of index, which
> doesn't use stats. This can be done later as an additional feature.
> This will result in larger footprint, but I think it'd be the best
> choice if existing design allows having two different types of indexes.
>
> My 2c anyway.
>
> Regards,
> Michael

> Remove the statistics, I don't use data-aware UI controls anyway, they are
> problematic. Using C/S exclusively, I run my queries, fill my UI controls,
> and close the query.
> Go in
> Get what you need
> Get out

+1

Michael,

<< Only if they don't use UI. Most database applications do. >>

I understand, but that wasn't my point.  My point was what the client
application does with the data cannot be the *primary* concern for a
database engine/server.  It's primary concern must be the data itself, and
the performance/integrity/ease-of-use issues involved with its processing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Well, i don't have any client with 800k records. Most of my clients are
ranging to 1k (highest) >>

In that case, you could probably get away with counting records for
positions, etc. and not experience that much of a performance hit in doing
so.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< I think it would be best if it is made as an option for a particular
index if someone needs to update a huge table in the described manner. >>

By then it's too late, however, if the index is already using statistics.
IOW, it's not something that will be easily turned on or off - the physical
structure of the index has to change, meaning that the index would have to
be dropped and then re-added.  And that doesn't even begin to cover the
difficulties involved with allowing constraints to specify one type of index
or another.  Right now, and probably this will stay this way, constraints
are just constraints - the fact that ElevateDB uses an index internally to
enforce them (primary, unique, foreign) is an implementation detail that is
not covered in the SQL because it's of no concern to the developer.

<< This way my suggestion is: do not remove the statistics at first. Create
a separate implementation of different type of index, which doesn't use
stats. This can be done later as an additional feature. This will result in
larger footprint, but I think it'd be the best choice if existing design
allows having two different types of indexes. >>

The problem is that it's more than an additional feature.  It's a structure
change, which involves a lot more difficulties than may seem apparent at
first, especially with regard to trying to do both stats and non-stats.
That is why I specifically mentioned that it's an either-or choice.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< One positive side affect of this solution is that you will later be able
to add other types of indexes, like spatial indexes, etc.I think it's
important to keep the design as open and extensibleas possible. Also a great
way to postpone things and release a preview faster . >>

I understand, but spatial indexes, etc. are separate index types only.  As I
mentioned before, stats in the indexes affect constraints and other things
that aren't just simple indexes that can be added and dropped at will.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Tim Young [Elevate Software] wrote:
....
> 1) Accurate row sequence numbers, regardless of the active index and
> even with ranges set (but not filters).  This also means an accurate
> grid scrollbar when there are a) no filters or ranges or b) just
> ranges set on the table cursor.

Unfortunately, that's something I need in several applications. Some
customers don't want a 3-state scrollbar, and it's not possible to turn
these grids to "load all records" (I only use DevExpress grids).

Ralf

Tim,

Tim Young [Elevate Software] wrote:
....
> The modifications are very minor, but the ramifications for doing the
> changes/not doing the changes will be with ElevateDB for its
> lifetime, so the decision has to be made now, unfortunately.

I know that I have no idea whatsoever how ElevateDB works under the hood,
but... what about defining that while creating the table? So we can choose
for each project what suits best. That is of course not an option if you end
up with two very different file formats.

Ralf

Tim

> Well, it's certainly possible to write a grid that could do what you want.
> However, I doubt if I would be the one to do it since that's kind of
> outside of our scope of interest.

Stay away from this suggestion and just code database programs.

> I understand, but the UI is not necessarily the prime factor in deciding
> what is best for a database engine/server.

Ok, I understand your point. The main concerns about database engine always
is related with performance, integrity and the last (user interface).

Eduardo

Hello Jose,

> Ok, I understand your point. The main concerns about database engine always
> is related with performance, integrity and the last (user interface).

To a big application that needs this power yes. But i guess
there are DBISAM developers that bought DBISAM for
Simple GUI Database applications like me. Anyhow what i can
see is that Tim has one choice. If he wants to Target EDB
for enterprises (which speed is matter) then it has to remove
the statistics else for the other he has to leave them.

A better way is to Vote through web ? ...

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr