22,209
社区成员
发帖
与我相关
我的任务
分享如何判断一个语句是Select字句还是Where子句.
计划给用户设计一种的表达式.即可以做为求值表达式,也可以做为过滤表达式,用以拼接到SQL中.这种表达式主要是想提供给普通用户使用,不需要他们懂SQL.同时这种表达式也可以提供给高级用户使用,他们懂SQL.
对于普通用户来说,求值表达式不会以Select开头,过滤表达式也不会也Where开头.
现在我要怎样判断用户输入的这串表达式时Select子句还是where子句呢?
对于普通用户来说,求值表达式不会以Select开头,过滤表达式也不会也Where开头.
现在我要怎样判断用户输入的这串表达式时Select子句还是where子句呢?
...全文
请发表友善的回复…
发表回复
三断笛 2011-11-29
- 打赏
- 举报
[Quote=引用 11 楼 roy_88 的回复:]
這個的需求沒意義，還不如直接文檔式記載（某某存儲過程。。。）
[/Quote]
支持有某某存储过程这种写法呢,参数由用户填写.还支持对存储过程的数学运算.
這個的需求沒意義，還不如直接文檔式記載（某某存儲過程。。。）
[/Quote]
支持有某某存储过程这种写法呢,参数由用户填写.还支持对存储过程的数学运算.
中国风 2011-11-29
- 打赏
- 举报
這個的需求沒意義，還不如直接文檔式記載（某某存儲過程。。。）
三断笛 2011-11-29
- 打赏
- 举报
问题解决了,用正则判断.
首先,这个表达式是Select子句,则它只会是求值表达式,不会是赋值表达式.
若该语句以Select开头,则为Select子句
若该语句以Where开头,则为Where子句
若该语句不包含=,>,<,>=,<=,<>,!=,LIKE,IN,Exists运算符,则为Select子句
若该语句包含上符运算符,则取出运算符首次出现的位置,如果是以=,>,>=,<=,<>,!=,LIKE,IN,则必须是在Case子句中,而且必须是搜索Case格式,而能是简单Case格式.
如只能case when a=b then ,case when exists(....)
否则为Where子句.不考虑语法错误.
首先,这个表达式是Select子句,则它只会是求值表达式,不会是赋值表达式.
若该语句以Select开头,则为Select子句
若该语句以Where开头,则为Where子句
若该语句不包含=,>,<,>=,<=,<>,!=,LIKE,IN,Exists运算符,则为Select子句
若该语句包含上符运算符,则取出运算符首次出现的位置,如果是以=,>,>=,<=,<>,!=,LIKE,IN,则必须是在Case子句中,而且必须是搜索Case格式,而能是简单Case格式.
如只能case when a=b then ,case when exists(....)
否则为Where子句.不考虑语法错误.
三断笛 2011-11-28
- 打赏
- 举报
[Quote=引用楼主 xxyj6450 的回复:]
计划给用户设计一种的表达式.即可以做为求值表达式,也可以做为过滤表达式,用以拼接到SQL中.这种表达式主要是想提供给普通用户使用,不需要他们懂SQL.同时这种表达式也可以提供给高级用户使用,他们懂SQL.
对于普通用户来说,求值表达式不会以Select开头,过滤表达式也不会也Where开头.
现在我要怎样判断用户输入的这串表达式时Select子句还是where子句呢?
[/Quote]
对于高级用户,如果输入了Select那当然是作为Select子句.主要是对于普通用户,他们可以不录入这些关键字.
而对于一些复杂的计算当然只能是我们写好函数,作为模板,让用户设置参数.
我设计这种表达式主要是面向有一定计算机水平,能编写一些简单表达式的会计人员,市场政策制定人员,等等,高等的开发人员也可以编写比较复杂的语句使用,这样不必任何需求改动都让开发人员处理,有利于系统维护,而且每次修改都会有详细的操作记录,有利于责任分摊,不会啥事都赖IT了.
计划给用户设计一种的表达式.即可以做为求值表达式,也可以做为过滤表达式,用以拼接到SQL中.这种表达式主要是想提供给普通用户使用,不需要他们懂SQL.同时这种表达式也可以提供给高级用户使用,他们懂SQL.
对于普通用户来说,求值表达式不会以Select开头,过滤表达式也不会也Where开头.
现在我要怎样判断用户输入的这串表达式时Select子句还是where子句呢?
[/Quote]
对于高级用户,如果输入了Select那当然是作为Select子句.主要是对于普通用户,他们可以不录入这些关键字.
而对于一些复杂的计算当然只能是我们写好函数,作为模板,让用户设置参数.
我设计这种表达式主要是面向有一定计算机水平,能编写一些简单表达式的会计人员,市场政策制定人员,等等,高等的开发人员也可以编写比较复杂的语句使用,这样不必任何需求改动都让开发人员处理,有利于系统维护,而且每次修改都会有详细的操作记录,有利于责任分摊,不会啥事都赖IT了.
三断笛 2011-11-27
- 打赏
- 举报
[Quote=引用 3 楼 p2227 的回复:]
这种东西就不要做在数据库层了，做在应用程序上吧
[/Quote]
我们的平台我们是不能改源代码的,我只能在数据库上用CLR做
这种东西就不要做在数据库层了，做在应用程序上吧
[/Quote]
我们的平台我们是不能改源代码的,我只能在数据库上用CLR做
三断笛 2011-11-27
- 打赏
- 举报
[Quote=引用 1 楼 qianjin036a 的回复:]
不可行.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
[/Quote]
所以我希望设计一种非常简单的表达式,能够让用户使用中文表达式书写,并且可以简单地从数据库中取出数据,而且已经设计了一个表达式设计器,可以比较方便地帮助用户录入一些比较简单的表达式,当然,复杂的表达式还是得IT来解决.
这就是我的目的.现在已经实现了一部分,能执行一些运算,但现在这里有些卡住了,主要是条件表达式的处理上.
我设计的是,
用户输入的表达式如果是select 子句,就根据Select的返回值判断条件是否为真.
如果用户输入的表达式是Where子句,就判断是否有数据返回,有数据返回则为真,否则为假.
所以同一个表达式既有可能是Select 子句或Where子句
不可行.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
[/Quote]
所以我希望设计一种非常简单的表达式,能够让用户使用中文表达式书写,并且可以简单地从数据库中取出数据,而且已经设计了一个表达式设计器,可以比较方便地帮助用户录入一些比较简单的表达式,当然,复杂的表达式还是得IT来解决.
这就是我的目的.现在已经实现了一部分,能执行一些运算,但现在这里有些卡住了,主要是条件表达式的处理上.
我设计的是,
用户输入的表达式如果是select 子句,就根据Select的返回值判断条件是否为真.
如果用户输入的表达式是Where子句,就判断是否有数据返回,有数据返回则为真,否则为假.
所以同一个表达式既有可能是Select 子句或Where子句
三断笛 2011-11-27
- 打赏
- 举报
[Quote=引用 1 楼 qianjin036a 的回复:]
不可行.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
[/Quote]
不错,让用户输这些东西确实影响用户体验.这些我也有考虑过.
但是因为我们业务复杂,变化极快,每次业务变化都需要我们IT来写代码控制业务，相当麻烦．这是对条件控制．
另外,因为业务的复杂性,很多数据的计算都无法简单地统一,很多特殊性的,像计算薪资,计算毛利,积分之类,太过灵活,这些工作都要IT写代码来计算,所有这些都让IT来做,也是非常痛苦.
还有就是我们的C/S版业务平台有类似的表达式,但只给开发人员用,而我们的B/S版本系统却没能做到解析这些表达式,每次C/S平台有改动,B/S又要重新去改代码再发布,非常麻烦,所以我也计算同时把这个问题解决让,让B/S系统和C/S系统同步.
不可行.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
[/Quote]
不错,让用户输这些东西确实影响用户体验.这些我也有考虑过.
但是因为我们业务复杂,变化极快,每次业务变化都需要我们IT来写代码控制业务，相当麻烦．这是对条件控制．
另外,因为业务的复杂性,很多数据的计算都无法简单地统一,很多特殊性的,像计算薪资,计算毛利,积分之类,太过灵活,这些工作都要IT写代码来计算,所有这些都让IT来做,也是非常痛苦.
还有就是我们的C/S版业务平台有类似的表达式,但只给开发人员用,而我们的B/S版本系统却没能做到解析这些表达式,每次C/S平台有改动,B/S又要重新去改代码再发布,非常麻烦,所以我也计算同时把这个问题解决让,让B/S系统和C/S系统同步.
-晴天 2011-11-26
- 打赏
- 举报
[Quote=引用 3 楼 p2227 的回复:]
这种东西就不要做在数据库层了，做在应用程序上吧
[/Quote]
楼主说的应该就是应用.
这涉及到软件的界面友好程度.
这种东西就不要做在数据库层了，做在应用程序上吧
[/Quote]
楼主说的应该就是应用.
这涉及到软件的界面友好程度.
p2227 2011-11-26
- 打赏
- 举报
这种东西就不要做在数据库层了，做在应用程序上吧
--小F-- 2011-11-26
- 打赏
- 举报
没懂意思。
-晴天 2011-11-26
- 打赏
- 举报
不可行.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
如果普通用户给你输了一个 seleect ,你该算它是什么语句呢?
通行的方法是,将表达式的命令子句做成选择,让最终用户选择命令,同时,在选择不同命令时,所给的条件选项不同,这样才能获得较好的效果.
我的经验是,做软件的时候,尽量少让用户干输入内容的事情,因为,他输的,很多情况下不是数据库里能保存的.
