MS SQL Server - 过多的限制...... [英] MS SQL Server - a plethora of limitations...
问题描述
为什么会这样，微软设法用人类已知的每个铃声和口哨设备编写操作系统和办公室
应用程序。然而，即使经过多年和多年的开发，他们仍然无法生成一个体面的MS SQL Server版本，一个没有过多的缺陷和
限制？就个人而言，我要解雇MS SQL Server首席架构师，
开始解决一些基本问题并做MS最擅长的事情 - 复制其竞争对手的最佳功能。
这里有几个原因让我觉得MS SQL Server仍然是一堆垃圾，
并且永远不会有很多开发者选择RDBMS：
1.在多语句表值函数表中不能使用域
定义
2.否table.column.datatype MYTABLE.MYCOLUMN％TYPE的概念
函数/ proc参数，变量。模式演变将需要对dep函数/过程进行
更改。
3.无法从存储的内部调用非扩展用户定义的过程
proc - 防止重复使用代码
4.不创建或替换函数/过程。对procs的更改
需要从create更改为alter，或者drop然后创建
5.函数必须在最终语句中返回结果 - 需要
过度使用局部变量。为什么!!! ???
6.没有用户可指定的日期格式例程 - 必须使用转换为
有限的选项
7.没有树木行走机制，不易穿越层次结构
8.带参数的调用程序要求用户也需要
指定哪些是超出范围
9.存储的Proc递归限制只有32个嵌套级别，而不是堆栈大小监控的
。
10.删除时没有设置空引用完整性，这是关系数据库中的基本数据，必须通过触发器来完成。 Yuk。
11.数据库表没有分区
12.无法在存储函数中引发错误。没有办法通知用户
不正确的参数等。
13.没有设施用于子过程/功能 - 用于本地化代码
规范化。
14.无功能超载
15.没有将类似的过程/功能分组为集体的概念
包 - 可能意味着1000次触发而不是少数几个包。
16.非标准func / proc调用 - proc非括号但是，
函数定义并用括号调用
17.表变量中的有限列名长度/多语句
表值函数表定义
18.没有交叉，减去运算符以补充联盟和工会所有
19.没有异常处理 - 我需要更多关于这个有趣的事情
要求？
20.使用proc参数传递的select语句没有处理
为null例如
创建过程sp_t est .......
......
从mytable中选择@MyID = ID
br />
其中parent_id = @ parent_id。
如果@parent_id为null，即使值为null_id $ id
，select也不会返回任何内容存在。
21没有用于存储过程/函数的布尔类型。 SQL标准确实
允许布尔值（null，FALSE，TRUE）
22重复直到 - （后谓词循环），while循环可以执行
这个但是经常需要执行一次额外检查
23当从
获取时，没有相当于光标或表％ROWTYPE列游标，所有绑定变量都必须单独声明
24. SQL Server中的声明性删除级联充其量只是垃圾 - 例如
在DELETE或UPDATE产生的所有级联
引用操作的列表中，任何表都不能出现多次。几乎所有我已尝试过的其他RDBMS似乎都在管理它。
创建表ForKey
（
MyID int not null identity primary key，
MyText varchar（30）
）
go
创建表格参考
（
SomeID int非null主键，
RefID1 int非null外键引用ForKey（MyID） ）关于删除
级联，
RefID2 int非null外键引用ForKey（MyID）on delete
cascade
）
服务器：消息1785，16级，状态1，行2
介绍FOREIGN KEY约束''FK__Refs__RefID2__1BFD2C07''
表''Refs''可能导致循环或多个
级联路径。指定ON DELETE NO ACTION或ON UPDATE NO ACTION，或
修改其他FOREIGN KEY约束。
服务器：Msg 1750，Level 16，State 1，Line 2
无法创建约束。查看以前的错误。
25.如果不删除所有依赖项，域名也不能更改
（存储过程/ funcs）即使类型没有改变但是说规模和
精度 - 这太荒谬了。域名有什么意义？
26.没有for循环，而循环可以执行此操作，但结果代码是
不清楚或整洁
27.在存储的procs / funcs中不能使用CURDATE（）。怎么废话
那个？
不要为MS找借口，因为我有数百个，其他人都有
任何？
Jeager
Why is it, Microsoft manage to write operating systems and office
applications with every bell and whistle facility known to man. Yet,
even after years and years of development they still cannot produce a
decent version of MS SQL Server, one without a plethora of flaws and
limitations? Personally I''d sack the MS SQL Server Chief Architect,
start addressing some fundementals and do what MS do best - copy the
best functionality of their competitors.
Here''s a few reasons why I feel MS SQL Server is still a load of crap,
and will never be many developers RDBMS of choice :
1. Can''t use domains in Multi-statement table-valued function table
definition
2. No concept of table.column.datatype MYTABLE.MYCOLUMN%TYPE for
function / proc parameters, variables. Schema evolution will require
changes to dep functions / procs.
3. Cannot call non extended user defined procedure from within stored
proc - prevents code re-use
4. No create or replace for functions / procs. Changes to procs
require either a change from create to alter, or drop then create
5. Functions must return result on final statement - requires
excessive use of local variables. Why!!!???
6. No user specifiable date format routines - must use convert with
limited options
7. No treewalk mechanism, not easy to traverse hierarchical structure
8. Calling procedures with out parameters require user to also
specifiy which are out params
9. Stored Proc recursion limitations to only 32 nested levels, rather
than monitoring by stack size.
10. No on delete set null referential integrity, this is fundemental
in relational databases, has to be done by trigger. Yuk.
11. No partitioning on db tables
12. Cannot raiseerror in stored functions. No way to inform user of
incorrect parameters etc.
13. No facility for sub - procs / funcs - for localised code
normalisation.
14. No function overloading
15. No concept of grouping similar procs / functions into a collective
package - can mean 1000s of procs rather than a handful of packages.
16. Non standard func / proc calling - proc non parenthesised but,
function defined and called with parenthesis
17. Limited column name length in table variables / Multi-statement
table-valued function table definitions
18. No intersect, minus operators to complement union and union all
19. No exception handling - need I say more about this fundemental
requirement?
20. No handling for select statements using proc parameters passed in
as null e.g.
create procedure sp_test.......
......
select @MyID = ID
from mytable
where parent_id = @parent_id.
If @parent_id is null, select will not return anything even if values
for null parent_id exist.
21 No boolean type for use in stored procs / funcs. SQL standards do
allow booleans (null, FALSE, TRUE)
22 No repeat until - (post predicate loops), while loops can perform
this but one extra check often has to be performed
23 No equivalent to cursor or table %ROWTYPE, when fetching from a
many column cursor, all bind variables have to be declared
individually
24. Declarative Delete cascade in SQL Server is at best rubbish - e.g.
No table can appear more than once in the list of all cascading
referential actions that result from the DELETE or UPDATE. Almost all
other RDBMS I''ve tried seems to manage it.
Create Table ForKey
(
MyID int not null identity primary key,
MyText varchar(30)
)
go
Create Table Refs
(
SomeID int not null primary key,
RefID1 int not null foreign key references ForKey(MyID) on delete
cascade,
RefID2 int not null foreign key references ForKey(MyID) on delete
cascade
)
Server: Msg 1785, Level 16, State 1, Line 2
Introducing FOREIGN KEY constraint ''FK__Refs__RefID2__1BFD2C07'' on
table ''Refs'' may cause cycles or multiple
cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or
modify other FOREIGN KEY constraints.
Server: Msg 1750, Level 16, State 1, Line 2
Could not create constraint. See previous errors.
25. Domains cannot be altered without dropping all dependencies
(stored procs / funcs) even if type isn''t changed but say scale and
precision- this is ridiculous. What is the point of domains?
26. No "for loop", while loops can perform this, but resultant code is
not as clear or tidy
27. Can''t use CURDATE() inside stored procs / funcs. How crap is
that?
Don''t try and make excuses for MS as I have hundreds, anyone else have
any?
Jeager
推荐答案
评论内联。
Comments inline.
1.不能在多语句表值函数表中使用域
定义
用户定义的数据类型？这可以在具有UDT的Yukon中解决。 （我
知道，明天堵塞......）
2.没有table.column.datatype MYTABLE.MYCOLUMN％TYPE的概念
function / proc参数，变量。模式演变需要对dep函数/过程进行更改。
是的。虽然Oracle的列和行类型
函数所解决的更改肯定是代码维护的一小部分，但是当架构发生变化时需要
。
3.无法从存储的
proc中调用非扩展用户定义的程序 - 防止代码重复使用
你*可以*那样做。你不能在UDF中调用SP，并且有很好的原因（确定性）。
4.没有创建或替换函数/过程。对procs的更改
需要从create更改为alter，或者drop然后创建
这确实是一个不错的功能。
5.函数必须在最终语句中返回结果 - 需要过度使用局部变量。为什么！！！？？？
不确定这意味着什么。
6.没有用户可指定的日期格式例程 - 必须使用转换为
有限的选项
您可以编写自己的代码但转换日期字符串实际上是ETL
函数 - 使用DTS或其他工具。
7.没有树木行走机制，不容易遍历层次结构
这不太正确。扩展
*邻接列表*层次结构并不是一种非迭代的方法。其他层次模型使这很容易做到。
Yukon的CTE将解决与邻接层次结构相关的限制。
8.调用带有参数的程序要求用户也
指定哪些是参数
为什么这是一个问题？
10.没有关于删除设置空参照完整性，这是有趣的
在关系数据库中，必须通过触发器来完成。育。
我同意'不方便。
11.数据库表没有分区
分区视图是SQLServer替代方案。
12.无法在存储函数中引发错误。无法通知用户
错误的参数等。
没错，这有点烦人。
9.存储Proc递归限制到只有32个嵌套级别，而不是通过堆栈大小监控。
13.没有子procs / funcs设施 - 用于本地化代码
规范化。
15.没有将类似的过程/功能分组到集合包中的概念 - 可能意味着1000个过程而不是少数几个包。
16.非标准的func / proc调用 - proc非括号但是，
函数定义并用括号
调用26.否for循环，while循环可以执行此操作，但结果代码是不是很清楚或整洁
Transact SQL并不打算成为一个功能齐全的编程语言。
..Net是微软的开发平台。将数据中的基本数据操作保存在数据库中，中间层中的逻辑更为复杂。
17.表变量中的有限列名长度/多语句
表估价的函数表定义
您是否知道允许* un * limited
长度的标识符的数据库或语言？最大长度为128个字符。对大多数人来说当然足够了！
18.没有交叉，减去运算符以补充联盟和联盟所有
True。虽然这对你自己来说是微不足道的。
19.没有异常处理 - 我需要更多地谈论这个有趣的要求吗？
Yukon的错误处理得到改善，但是这很痛苦。
20.没有使用传递的proc参数处理select语句
as null例如
创建程序sp_test .......
.....
从mytable中选择@MyID = ID
parent_id = @ parent_id。
如果@parent_id为null，即使存在null parent_id的值
，select也不会返回任何内容。
这只是ANSI标准处理NULL。使用IS NULL。
21没有用于存储过程/函数的布尔类型。 SQL标准允许布尔值（null，FALSE，TRUE）
否，但你可以返回T或F或F。或者别的东西。为什么这是一个
限制？它仍然只是一个标量值。
22没有重复，直到 - （后谓词循环），而循环可以执行
这个但是经常需要执行一次额外的检查
是。
23没有相当于游标或表％ROWTYPE，当从许多列游标中获取时，必须声明所有绑定变量<单独
您多久使用一次游标？我认为除了
之外，我还没有写过一些管理流程。
24. SQL Server中的声明性删除级联充其量只是垃圾 - 例如<没有表可以在所有级联列表中出现多次
这是一个重要的限制，是的。
25. ...什么域名是什么？
你说的。就个人而言，我从不使用用户定义的数据类型。
27.在存储的procs / funcs中不能使用CURDATE（）。怎么废话呢？
您可以在过程中使用CURRENT_TIMESTAMP，GETDATE（）但不能在函数中使用。请参阅
我的回答3.
不要为MS找借口，因为我有数百人，其他人都有
任何？
1. Can''t use domains in Multi-statement table-valued function table
definition
User-defined datatypes? That may be addressed in Yukon which has UDTs. (I
know, "jam tomorrow...")
2. No concept of table.column.datatype MYTABLE.MYCOLUMN%TYPE for
function / proc parameters, variables. Schema evolution will require
changes to dep functions / procs.
True. Although the changes addressed by Oracle''s column and row type
functions are surely a fairly small subset of the code maintenance required
when the schema changes.
3. Cannot call non extended user defined procedure from within stored
proc - prevents code re-use
You *can* do that. You can''t call SPs from within a UDF and there are good
reasons why not (determinism).
4. No create or replace for functions / procs. Changes to procs
require either a change from create to alter, or drop then create
That would indeed be a nice feature to have.
5. Functions must return result on final statement - requires
excessive use of local variables. Why!!!???
Not sure what this means.
6. No user specifiable date format routines - must use convert with
limited options
You can code your own but converting date strings is really an ETL
function - use DTS or some other tool.
7. No treewalk mechanism, not easy to traverse hierarchical structure
That''s not quite correct. There isn''t a non-iterative way to expand an
*adjacency list* hierarchy. Other hierarchy models make this easy to do.
CTEs in Yukon will address the limitation relevant to adjacency hierarchies.
8. Calling procedures with out parameters require user to also
specifiy which are out params
Why is that a problem?
10. No on delete set null referential integrity, this is fundemental
in relational databases, has to be done by trigger. Yuk.
I agree that''s inconvenient.
11. No partitioning on db tables
Partitioned views are the SQLServer alternative.
12. Cannot raiseerror in stored functions. No way to inform user of
incorrect parameters etc.
True, that''s a little annoying.
9. Stored Proc recursion limitations to only 32 nested levels, rather
than monitoring by stack size.
13. No facility for sub - procs / funcs - for localised code
normalisation.
14. No function overloading
15. No concept of grouping similar procs / functions into a collective
package - can mean 1000s of procs rather than a handful of packages.
16. Non standard func / proc calling - proc non parenthesised but,
function defined and called with parenthesis 26. No "for loop", while loops can perform this, but resultant code is
not as clear or tidy
Transact SQL isn''t intended to be a fully featured programming language.
..Net is Microsoft''s development platform. Keep basic data manipulation in
the database, more complex logic in the middle tier.
17. Limited column name length in table variables / Multi-statement
table-valued function table definitions
Do you know of a database or language that allows identifiers of *un*limited
length? The maximum length is 128 characters. Surely enough for most people!
18. No intersect, minus operators to complement union and union all
True. Although this is trivial to code yourself.
19. No exception handling - need I say more about this fundemental
requirement?
Error handling is improved in Yukon but yes it''s a pain.
20. No handling for select statements using proc parameters passed in
as null e.g.
create procedure sp_test.......
.....
select @MyID = ID
from mytable
where parent_id = @parent_id.
If @parent_id is null, select will not return anything even if values
for null parent_id exist.
That''s just ANSI Standard handling of NULLs. Use IS NULL.
21 No boolean type for use in stored procs / funcs. SQL standards do
allow booleans (null, FALSE, TRUE)
No, but you can return "T" or "F" or something else instead. Why is that a
limitation? It''s still just a single scalar value.
22 No repeat until - (post predicate loops), while loops can perform
this but one extra check often has to be performed
Yes.
23 No equivalent to cursor or table %ROWTYPE, when fetching from a
many column cursor, all bind variables have to be declared
individually
How often do you use cursors? I don''t think I''ve ever written one except for
some administrative processes.
24. Declarative Delete cascade in SQL Server is at best rubbish - e.g.
No table can appear more than once in the list of all cascading
This is a significant limitation, yes.
25. ... What is the point of domains?
You said it. Personally, I never use user-defined datatypes.
27. Can''t use CURDATE() inside stored procs / funcs. How crap is
that?
You can use CURRENT_TIMESTAMP, GETDATE() in procs but not in functions. See
my answer to 3.
Don''t try and make excuses for MS as I have hundreds, anyone else have
any?
很多。但如果它困扰你为什么不使用其他产品呢？
-
David Portas
SQL Server MVP
-
Lots. But if it bothers you why not use another product?
--
David Portas
SQL Server MVP
--
评论内联。
Comments inline.
1.无法在多语句表格中使用域名 - 有价值的函数表
定义
用户定义的数据类型？这可以在具有UDT的Yukon中解决。 （我
知道，明天堵塞......）
2.没有table.column.datatype MYTABLE.MYCOLUMN％TYPE的概念
function / proc参数，变量。模式演变需要对dep函数/过程进行更改。
是的。虽然Oracle的列和行类型
函数所解决的更改肯定是代码维护的一小部分，但是当架构发生变化时需要
。
3.无法从存储的
proc中调用非扩展用户定义的程序 - 防止代码重复使用
你*可以*那样做。你不能在UDF中调用SP，并且有很好的原因（确定性）。
4.没有创建或替换函数/过程。对procs的更改
需要从create更改为alter，或者drop然后创建
这确实是一个不错的功能。
5.函数必须在最终语句中返回结果 - 需要过度使用局部变量。为什么！！！？？？
不确定这意味着什么。
6.没有用户可指定的日期格式例程 - 必须使用转换为
有限的选项
您可以编写自己的代码但转换日期字符串实际上是ETL
函数 - 使用DTS或其他工具。
7.没有树木行走机制，不容易遍历层次结构
这不太正确。扩展
*邻接列表*层次结构并不是一种非迭代的方法。其他层次模型使这很容易做到。
Yukon的CTE将解决与邻接层次结构相关的限制。
8.调用带有参数的程序要求用户也
指定哪些是参数
为什么这是一个问题？
10.没有关于删除设置空参照完整性，这是有趣的
在关系数据库中，必须通过触发器来完成。育。
我同意'不方便。
11.数据库表没有分区
分区视图是SQLServer替代方案。
12.无法在存储函数中引发错误。无法通知用户
错误的参数等。
没错，这有点烦人。
9.存储Proc递归限制到只有32个嵌套级别，而不是通过堆栈大小监控。
13.没有子procs / funcs设施 - 用于本地化代码
规范化。
15.没有将类似的过程/功能分组到集合包中的概念 - 可能意味着1000个过程而不是少数几个包。
16.非标准的func / proc调用 - proc非括号但是，
函数定义并用括号
调用26.否for循环，while循环可以执行此操作，但结果代码是不是很清楚或整洁
Transact SQL并不打算成为一个功能齐全的编程语言。
..Net是微软的开发平台。将数据中的基本数据操作保存在数据库中，中间层中的逻辑更为复杂。
17.表变量中的有限列名长度/多语句
表估价的函数表定义
您是否知道允许* un * limited
长度的标识符的数据库或语言？最大长度为128个字符。对大多数人来说当然足够了！
18.没有交叉，减去运算符以补充联盟和联盟所有
True。虽然这对你自己来说是微不足道的。
19.没有异常处理 - 我需要更多地谈论这个有趣的要求吗？
Yukon的错误处理得到改善，但是这很痛苦。
20.没有使用传递的proc参数处理select语句
as null例如
创建程序sp_test .......
.....
从mytable中选择@MyID = ID
parent_id = @ parent_id。
如果@parent_id为null，即使存在null parent_id的值
，select也不会返回任何内容。
这只是ANSI标准处理NULL。使用IS NULL。
21没有用于存储过程/函数的布尔类型。 SQL标准允许布尔值（null，FALSE，TRUE）
否，但你可以返回T或F或F。或者别的东西。为什么这是一个
限制？它仍然只是一个标量值。
22没有重复，直到 - （后谓词循环），而循环可以执行
这个但是经常需要执行一次额外的检查
是。
23没有相当于游标或表％ROWTYPE，当从许多列游标中获取时，必须声明所有绑定变量<单独
您多久使用一次游标？我认为除了
之外，我还没有写过一些管理流程。
24. SQL Server中的声明性删除级联充其量只是垃圾 - 例如<没有表可以在所有级联列表中出现多次
这是一个重要的限制，是的。
25. ...什么域名是什么？
你说的。就个人而言，我从不使用用户定义的数据类型。
27.在存储的procs / funcs中不能使用CURDATE（）。怎么废话呢？
您可以在过程中使用CURRENT_TIMESTAMP，GETDATE（）但不能在函数中使用。请参阅
我的回答3.
不要为MS找借口，因为我有数百人，其他人都有
任何？
1. Can''t use domains in Multi-statement table-valued function table
definition
User-defined datatypes? That may be addressed in Yukon which has UDTs. (I
know, "jam tomorrow...")
2. No concept of table.column.datatype MYTABLE.MYCOLUMN%TYPE for
function / proc parameters, variables. Schema evolution will require
changes to dep functions / procs.
True. Although the changes addressed by Oracle''s column and row type
functions are surely a fairly small subset of the code maintenance required
when the schema changes.
3. Cannot call non extended user defined procedure from within stored
proc - prevents code re-use
You *can* do that. You can''t call SPs from within a UDF and there are good
reasons why not (determinism).
4. No create or replace for functions / procs. Changes to procs
require either a change from create to alter, or drop then create
That would indeed be a nice feature to have.
5. Functions must return result on final statement - requires
excessive use of local variables. Why!!!???
Not sure what this means.
6. No user specifiable date format routines - must use convert with
limited options
You can code your own but converting date strings is really an ETL
function - use DTS or some other tool.
7. No treewalk mechanism, not easy to traverse hierarchical structure
That''s not quite correct. There isn''t a non-iterative way to expand an
*adjacency list* hierarchy. Other hierarchy models make this easy to do.
CTEs in Yukon will address the limitation relevant to adjacency hierarchies.
8. Calling procedures with out parameters require user to also
specifiy which are out params
Why is that a problem?
10. No on delete set null referential integrity, this is fundemental
in relational databases, has to be done by trigger. Yuk.
I agree that''s inconvenient.
11. No partitioning on db tables
Partitioned views are the SQLServer alternative.
12. Cannot raiseerror in stored functions. No way to inform user of
incorrect parameters etc.
True, that''s a little annoying.
9. Stored Proc recursion limitations to only 32 nested levels, rather
than monitoring by stack size.
13. No facility for sub - procs / funcs - for localised code
normalisation.
14. No function overloading
15. No concept of grouping similar procs / functions into a collective
package - can mean 1000s of procs rather than a handful of packages.
16. Non standard func / proc calling - proc non parenthesised but,
function defined and called with parenthesis 26. No "for loop", while loops can perform this, but resultant code is
not as clear or tidy
Transact SQL isn''t intended to be a fully featured programming language.
..Net is Microsoft''s development platform. Keep basic data manipulation in
the database, more complex logic in the middle tier.
17. Limited column name length in table variables / Multi-statement
table-valued function table definitions
Do you know of a database or language that allows identifiers of *un*limited
length? The maximum length is 128 characters. Surely enough for most people!
18. No intersect, minus operators to complement union and union all
True. Although this is trivial to code yourself.
19. No exception handling - need I say more about this fundemental
requirement?
Error handling is improved in Yukon but yes it''s a pain.
20. No handling for select statements using proc parameters passed in
as null e.g.
create procedure sp_test.......
.....
select @MyID = ID
from mytable
where parent_id = @parent_id.
If @parent_id is null, select will not return anything even if values
for null parent_id exist.
That''s just ANSI Standard handling of NULLs. Use IS NULL.
21 No boolean type for use in stored procs / funcs. SQL standards do
allow booleans (null, FALSE, TRUE)
No, but you can return "T" or "F" or something else instead. Why is that a
limitation? It''s still just a single scalar value.
22 No repeat until - (post predicate loops), while loops can perform
this but one extra check often has to be performed
Yes.
23 No equivalent to cursor or table %ROWTYPE, when fetching from a
many column cursor, all bind variables have to be declared
individually
How often do you use cursors? I don''t think I''ve ever written one except for
some administrative processes.
24. Declarative Delete cascade in SQL Server is at best rubbish - e.g.
No table can appear more than once in the list of all cascading
This is a significant limitation, yes.
25. ... What is the point of domains?
You said it. Personally, I never use user-defined datatypes.
27. Can''t use CURDATE() inside stored procs / funcs. How crap is
that?
You can use CURRENT_TIMESTAMP, GETDATE() in procs but not in functions. See
my answer to 3.
Don''t try and make excuses for MS as I have hundreds, anyone else have
any?
很多。但如果它困扰你为什么不使用其他产品呢？
-
David Portas
SQL Server MVP
-
Lots. But if it bothers you why not use another product?
--
David Portas
SQL Server MVP
--
Jeager（Je****@nowhere.com）写道：
Jeager (Je****@nowhere.com) writes:
为什么会这样，微软设法用人类已知的每个铃铛和哨子设备编写操作系统和办公室应用程序。然而，即使经过多年和多年的发展，他们仍然无法生成一个不错的MS SQL Server版本，没有太多的缺陷和
限制？我个人会解雇MS SQL Server首席架构师，开始解决一些基本问题并做MS最擅长的事情 - 复制其竞争对手的最佳功能。
这里'我认为MS SQL Server仍然是一堆垃圾的原因很少，而且永远不会有很多开发者选择RDBMS：
你提出的一些问题是SQL Server中肯定存在的弱点
有些意义。其中一些是在下一个版本的
SQL Server中解决的，但不是全部。
但是，你提出的其他问题，绝不保证你的大喊大叫
和大喊大叫。也许你有一个最喜欢的DBMS支持所有这些，
但我怀疑。并且DBMS可能没有SQL Server所具有的功能。
1.不能在多语句表值函数表中使用域
定义
你不能在任何地方使用域名，因为SQL Server没有
的概念。但如果你的意思是用户定义的数据类型，这有点愚蠢
限制。
2.没有table.column.datatype MYTABLE.MYCOLUMN％TYPE的概念
function / proc参数，变量。模式演变需要对dep函数/过程进行更改。
会很好，是的，但严重限制？ No.
3.无法从存储的
proc中调用非扩展用户定义的程序 - 防止代码重复使用
错误。但是你可能正在考虑从函数中调用SP。
看来你还没有理解函数的概念。当
MS引入函数时，他们采取了非常保守的方法，并且
决定函数可能不会改变数据库的状态。
当然，它们本来可以更宽松，但这也可以减少
，你可以使用一个功能。说你有：
SELECT ...
FROM tbl
加入some_fuction（）ON ..
现在，如果some_function更改了tbl中的数据，则可能会有不同的结果
，具体取决于优化程序访问表的顺序。你觉得
会是件好事吗？
4.没有创建或替换函数/ procs。对procs的更改
需要从create更改为alter，或者drop然后创建
没什么大不了的。请参阅 http://www.abaris.se/abaperls ，负责此事
完全是问题。 （这也解决了列表中的第一个问题。）
5.函数必须在最终语句中返回结果 - 要求过度使用局部变量。为什么！！！？？？
来吧，你称这是一个严重的问题。
6.没有用户可指定的日期格式例程 - 必须使用转换与
有限的选项
然后再次，最好将日期返回给客户。服务器
现在无法满足最终用户的偏好。
8.调用带有参数的程序要求用户也要指定哪些是超出参数$
Funky。 Sybase遗留的一部分。
9.存储Proc递归限制只有32个嵌套级别，而不是堆栈大小监视。
可能是件好事。我挖这个深刻的唯一一次是
然后我不应该。
10.没有关于删除设置null参照完整性，这是有趣的
在关系数据库中，必须通过触发器完成。育。
基础？
11.数据库表没有分区
您可以使用分区视图。分区表位于Yukon。
12.无法在存储函数中引发错误。无法通知用户
不正确的参数等。
鉴于SQL Server根本没有处理函数中出现的错误
，这个可能是件好事。 :-)
14.没有功能超载
您是否称这是一个严重的限制？那么，在育空地区，你将能够以.Net语言编程，所以你可以在你听到的内容中超载
。
15.没有将类似的过程/功能分组到集体包中的概念 - 可能意味着1000个过程而不是少数几个过程。
再一次，这没有任何保证你的帖子的语气。
16.非标准的func / proc调用 - proc非括号，但是，
使用括号定义和调用的函数
刺激，但它不是世界末日。
17.表变量中有限的列名长度/多语句
表值函数表定义
不是128个字符对你来说足够吗？
18.没有相交，减去运营商补充工会和工会所有
是的，这是缺失的，也没有任何添加的迹象。
19.没有异常处理 - 需要我说更多关于这个有趣的要求？
SQL2000中的错误处理非常糟糕。 Yukon从根本上改变了场景
。
20.使用在
中传递的proc参数的select语句没有处理为null例如
创建过程sp_test .. .......
从mytable中选择@MyID = ID
其中parent_id = @ parent_id。
如果@parent_id为null，则即使存在null parent_id的值
，select也不会返回任何内容。
错误。如果您需要此行为，可以使用SET ANSI_NULLS OFF。但是
我绝对不鼓励它。
21没有用于存储过程/函数的布尔类型。 SQL标准允许布尔值（null，FALSE，TRUE）
有点。适合我。
22没有重复，直到 - （后谓词循环），而循环可以执行
这个但是经常需要执行一次额外的检查
如果您想要一种具有良好控制结构的语言，请尝试传统的
。您甚至可以在Yukon的SQL Server中使用它们。
23没有等效于游标或表％ROWTYPE，当从多列游标中取出时，所有绑定变量都必须是宣布
单独
大不了。无论如何最好避免使用游标。
25.如果不删除所有依赖关系（存储的procs / funcs），即使类型没有改变但是说缩放和
，域也不能改变精确 - 这太荒谬了。域名有什么意义？
每天改变它们？我很怀疑。实际上，这个
是我不知道的功能，如果我想看到的话。你有这个
用户定义的数据类型（在SQL Server中仍然没有域名），这是
十进制（8,2），并且在15个大表中使用。现在你决定
来改变十进制类型（14,2）。由于您现在使类型更大，
SQL Server必须重建所有表。在一个单独的事务中。
27.在存储的procs / funcs中不能使用CURDATE（）。怎么废话呢？
Why is it, Microsoft manage to write operating systems and office
applications with every bell and whistle facility known to man. Yet,
even after years and years of development they still cannot produce a
decent version of MS SQL Server, one without a plethora of flaws and
limitations? Personally I''d sack the MS SQL Server Chief Architect,
start addressing some fundementals and do what MS do best - copy the
best functionality of their competitors.
Here''s a few reasons why I feel MS SQL Server is still a load of crap,
and will never be many developers RDBMS of choice :
Some of the issues you raise are certainly weaknesses in SQL Server of
some significance. Some of them are addressed in the next version of
SQL Server, but not all.
However, other issues you raise, do in no way warrant your yelling
and shouting. Maybe you have a favourite DBMS which supports all this,
but I doubt. And that DBMS is such case likely to be without features
that SQL Server has.
1. Can''t use domains in Multi-statement table-valued function table
definition
You can''t use domains anywhere, because SQL Server does not have the
concept. But if you mean user-defined datatypes, this is somewhat stupid
limitation.
2. No concept of table.column.datatype MYTABLE.MYCOLUMN%TYPE for
function / proc parameters, variables. Schema evolution will require
changes to dep functions / procs.
Would be nice, yes, but a serious restriction? No.
3. Cannot call non extended user defined procedure from within stored
proc - prevents code re-use
Wrong. But you are probably thinking of calling an SP from a function.
It appears that you have not understood the concept of a function. When
MS introduced functions, they took a very conservative approach and
decided that a function may not change the state of the database. Of
course, they could have been more lax, but that would also have reduced
where you can use a function. Say that you have:
SELECT ...
FROM tbl
JOIN some_fuction() ON ..
Now, if some_function changes data in tbl, you could different results
depending in which order the optimizer accesses the table. Do you think
that would be a good thing?
4. No create or replace for functions / procs. Changes to procs
require either a change from create to alter, or drop then create
No big deal. See http://www.abaris.se/abaperls which takes care of this
problem entirely. (And which also address the first issue on the list.)
5. Functions must return result on final statement - requires
excessive use of local variables. Why!!!???
Come on, you call this a serious issue.
6. No user specifiable date format routines - must use convert with
limited options
Then again, it''s better to return as date to the client. The server
cannot now which the preferences of the end user are.
8. Calling procedures with out parameters require user to also
specifiy which are out params
Funky. Part of the Sybase legacy.
9. Stored Proc recursion limitations to only 32 nested levels, rather
than monitoring by stack size.
Probably a good thing. The only times when I have dug this deep was
then I shouldn''t have.
10. No on delete set null referential integrity, this is fundemental
in relational databases, has to be done by trigger. Yuk.
Fundamental?
11. No partitioning on db tables
You can use partitioned views. Partition tables are in Yukon.
12. Cannot raiseerror in stored functions. No way to inform user of
incorrect parameters etc.
Given that SQL Server does not handle errors raised in functions well
at all, this is probably a good thing. :-)
14. No function overloading
And you are calling that a serious restriction? Well, in Yukon you will
be able to program in .Net languages, so there you be able to overload
to your hears content.
15. No concept of grouping similar procs / functions into a collective
package - can mean 1000s of procs rather than a handful of packages.
Again, that is nothing that warrants the tone of your post.
16. Non standard func / proc calling - proc non parenthesised but,
function defined and called with parenthesis
Irritating, but it''s not the end of the world.
17. Limited column name length in table variables / Multi-statement
table-valued function table definitions
Isn''t 128 chars enough for you?
18. No intersect, minus operators to complement union and union all
Yes, this is missing, and no signs of being added either.
19. No exception handling - need I say more about this fundemental
requirement?
Error handling in SQL2000 is really poor. Yukon changes the scene
radically.
20. No handling for select statements using proc parameters passed in
as null e.g.
create procedure sp_test.......
.....
select @MyID = ID
from mytable
where parent_id = @parent_id.
If @parent_id is null, select will not return anything even if values
for null parent_id exist.
Wrong. If you want this behaviour, you can use SET ANSI_NULLS OFF. But
I definitely to not encourage it.
21 No boolean type for use in stored procs / funcs. SQL standards do
allow booleans (null, FALSE, TRUE)
There is bit. Works for me.
22 No repeat until - (post predicate loops), while loops can perform
this but one extra check often has to be performed
If you want a language with good control structure, try a traditional
one. You will even be able to use them in SQL Server in Yukon.
23 No equivalent to cursor or table %ROWTYPE, when fetching from a
many column cursor, all bind variables have to be declared
individually
Big deal. Cursors are best avoided anyway.
25. Domains cannot be altered without dropping all dependencies
(stored procs / funcs) even if type isn''t changed but say scale and
precision- this is ridiculous. What is the point of domains?
To alter them each and every day? I seriously doubt. Actually, this
is the sort of feature I don''t know if I want to see. You have this
user-defined data type (still no domains in SQL Server), which is
decimal(8,2), and which is used in 15 big tables. Now you decide
to change the type decimal(14,2). Since you now make the type bigger,
SQL Server has to rebuild all tables. In one single transaction.
27. Can''t use CURDATE() inside stored procs / funcs. How crap is
that?
可能你的意思是getdate（），你可以在存储过程中使用它。
你不能使用它的函数，因为在查询中重复调用函数时，结果应该是查询期间任何给定输入参数
的保存。 />
-
Erland Sommarskog，SQL Server MVP， es****@sommarskog.se
SQL Server SP3联机丛书
http://www.microsoft.com/sql/techinf...2000/books.asp
这篇关于MS SQL Server - 过多的限制......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
