我已经通过了一项工作,我可以在我的应用程序中执行,也可以在SQL中执行:
我必须从字符串中得到一个可能如下所示的日期:
1234567-DSP-01/01-VER-01/01
或者像这样:
1234567-VER-01/01-DSP-01/01
但可能看起来像这样:
00 12345 DISCH 01/01-VER-01/01 XXX X XXXXX
耶。如果它是"DSP"
,那么我想要那个日期,如果"DISCH"
那么该日期。
我在SQL Server视图中提取数据,并且很乐意让视图为我转换数据。我的应用程序可以做到但会增加处理器时间。我想也可以看看数据是否可以在输入数据库之前进行操作。
感谢您的时间。
答案 0 :(得分:1)
一个选项是检查是否存在DSP或DISCH,然后根据需要对日期进行子串。
例如(我今天没有sqlserver所以我可以验证语法,抱歉)
select
date = case date_attribute
when charindex('DSP',date_attribute) > 0 then substring(date_attribute,beg,end)
when charindex('DISCH',date_attribute) > 0 then substring(date_attribute,beg,end)
else 'unknown'
end
from myTable
答案 1 :(得分:0)
如果您在视图中执行此操作,则在SQL上添加处理时间,这通常是一个更昂贵的资源,然后是应用程序,Web或其他类型的客户端。
我建议您在插入数据时尝试格式化数据,或者在应用程序层中处理。横向扩展应用层比调整SQL更容易。
修改强>
我说的是数据库服务器的物理资源通常比设计合理的应用服务器的物理资源更贵。这是因为水平扩展应用程序非常容易,在我看来,水平扩展数据库服务器的成本要高出一个数量级。特别是如果您处理事务数据库并需要管理合并
我并不是说不可能只是水平扩展数据库服务器是一项更加困难的任务,因此它更昂贵。我指出这一点的唯一原因是OP引起了对在app服务器和数据库服务器上使用CPU周期的担忧。我使用过的大多数应用程序都是以数据为中心的应用程序,它们通过GB的数据处理以获得用户的答案。我们最初将所有内容放在数据库服务器上,因为当时在经典的asp和vb6中更容易。随着时间的推移,DB服务器的负载越来越大,直到veritcally不再是一个选项。
数据库服务器还用于检索和连接数据。您应该将数据格式化为应用程序和业务规则(当然一般)
答案 2 :(得分:0)
不要在同一列中存储多个项目!
在插入行时将日期存储在自己的列中!