Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 Parttioning - Why does one work and not the other?

Author  Topic 

rockmoose
SQL Natt Alfen

3279 Posts

Posted - 2005-12-12 : 15:18:36
Hi all!

Sanity check....
Why does one type of check constraint work with this partitioned view and not the other?

create table x1(i int, c int check(c=10), primary key(i,c))
create table x2(i int, c int check(c=20), primary key(i,c))
--This partitioning column works
--create table x3(i int, c int check( (c<10) or (c>10 and c<20) or (c>20) ), primary key(i,c))
--This partitioning column does not work
create table x3(i int, c int check( (c<10 or c>10) and (c<20 or c>20)), primary key(i,c))
go

create view x as
select i,c from x1
union all
select i,c from x2
union all
select i,c from x3
go

insert x(i,c) select 342,2345632
go

select * from x

drop table x1,x2,x3
go
drop view x

Kristen
Test

22859 Posts

Posted - 2005-12-12 : 15:29:07
Sorry Rocky, haven't carefully examined this, but I did post the requirements for Horizontal Partitions a while back. Is it worth double checking that you haven't "breached" anything?

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55210&SearchTerms=Requirements+for+Horiztonal+Partitions

Kristen
Go to Top of Page

rockmoose
SQL Natt Alfen

3279 Posts

Posted - 2005-12-12 : 15:44:51
Hi Kristen,

Yeah, well I did read the documentation at least 2 times.
Mr Boole is pulling my leg.

Designing a partitioning scheme for a bunch of tables with carefully chosen constraints and indexes.
Moments later paff
--------------------------------
Server: Msg 4436, Level 16, State 12, Line 1
UNION ALL view 'x' is not updatable because a partitioning column was not found.

The worst part was not understanding what was going on, why!? why!?

rockmoose
Go to Top of Page

byrmol
Shed Building SQL Farmer

1591 Posts

Posted - 2005-12-12 : 16:11:52
>>The worst part was not understanding what was going on, why!? why!?
Without the source code you haven't got a chance mate!

The answer is..... It is a bug.

Anybody with SQL2005 please run this test and tell us the result

DavidM

Intelligent Design is NOT science.

A front-end is something that tries to violate a back-end.
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2005-12-12 : 16:13:46
I noticed that when it created the constraints, it did it this way:

not updatable:
(([c] < 10 or [c] > 10) and ([c] < 20 or [c] > 20))

updatable:
([c] < 10 or [c] > 10 and [c] < 20 or [c] > 20)

Maybe it sees the conditions in the first constraint as ranges that overlap, something that is not allowed across tables. Just my guess really, but you may be able to test it with other ranges that overlap to see if this idea holds up.





CODO ERGO SUM
Go to Top of Page

rockmoose
SQL Natt Alfen

3279 Posts

Posted - 2005-12-12 : 17:08:22
Thanx guys,

I can report that both check constraints work on SQL2005 RC2. So someone must have fixed this.
The partitioned views on SQL2000 seem a bit dodgy to me :-(
My homegrown polish boolean logic parser does a better job!

The query processor seems to detect the "overlap" range and discard the validity of the constraint to early.
Although if fully evaluated there is no logical overlap.

Here's the business problem where I intend to implement the partitioning:
Transaction tables (3) with apprx 60 mill rows, growing appx 5mill/mth.
95% of the transactions are done by automatic robots, 5% are done by "real" users.
So I want to offload the "more important" user data, that we want to save longer,
from the weight of all the robot transactions.
This is to make the db more manageable, and improve performance for the users (who actually view their transactions).

rockmoose
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2005-12-12 : 18:22:14
The constraint does not have to overlap with the ranges of the other tables to make the view not updatable. It is enough to make the view not updatable if the conditions within the constraint on one table overlap each other. See the code example below.

Kind to a silly quirk, but it doesn't look like it will be difficult to work around.



create table x1(i int, c int check(c<10), primary key(i,c))

create table x2(i int, c int check(c>20), primary key(i,c))

create table x3(i int, c int
check( (c between 11 and 18) and (c between 12 and 19) ), primary key(i,c))
go

create view x as
select i,c from x1
union all
select i,c from x2
union all
select i,c from x3
go
insert x(i,c) select 342,2345632
go

select * from x
go
drop table x1,x2,x3
go
drop view x



Server: Msg 4436, Level 16, State 12, Line 1
UNION ALL view 'x' is not updatable because a partitioning column was not found.
i c
----------- -----------

(0 row(s) affected)







CODO ERGO SUM
Go to Top of Page

rockmoose
SQL Natt Alfen

3279 Posts

Posted - 2005-12-12 : 18:45:50
Very quirky indeed.
I was upset because with logically equivalent constraints we get different results.

I agree with byrmol, this is a bug, not a feature.

quote:
BOL:
Each base table has a partitioning column whose key values are enforced by CHECK constraints. The key ranges of the CHECK constraints in each table do not overlap with the ranges of any other table. Any given value of the partitioning column must map to only one table. The CHECK constraints can only use these operators: BETWEEN, AND, OR, <, <=, >, >=, =.

Or itself!

Thanks for the support,
I feel more sane now, I was starting to worry about having become (even more) senile

>> Kind to a silly quirk, but it doesn't look like it will be difficult to work around.
I just hope there aren't any more quirks when we throw all the sprocs and business logic on the view!

rockmoose
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2005-12-12 : 19:21:51
Here's another nice little quirk. If you use OR instead of AND with the overlaped ranges, it works just fine.

Oh well, sounds like it's fixed in 2005.


create table x1(i int, c int check(c<10), primary key(i,c))

create table x2(i int, c int check(c>20), primary key(i,c))

create table x3(i int, c int
check( c between 11 and 19 OR c between 12 and 20), primary key(i,c))
go

create view x as
select i,c from x1
union all
select i,c from x2
union all
select i,c from x3
go
insert x(i,c) select 342,2345632
go

select * from x
go
drop table x1,x2,x3
go
drop view x



(1 row(s) affected)

i c
----------- -----------
342 2345632

(1 row(s) affected)



CODO ERGO SUM
Go to Top of Page
   

- Advertisement -