n****n
发帖数: 59 | 1 The current system in my company drives me crazy. There are just too many
stored procedures and many business logic are hard coded in them. So I
wonder how you guys set up and maintain database, and what is the best
practice in industry. Should we use more generic sprocs, dynamic sqls more
user defined types? Any way to keep business logic out of the system, or
least make things more transparent and easy to maintain? |
W*******e
发帖数: 1268 | 2 好多老系统都是这样的
我觉得有的三哥是有意这样做的
比如某些情况下，要改好了，可能这个DBA的位置就没了
【在 n****n 的大作中提到】
: The current system in my company drives me crazy. There are just too many
: stored procedures and many business logic are hard coded in them. So I
: wonder how you guys set up and maintain database, and what is the best
: practice in industry. Should we use more generic sprocs, dynamic sqls more
: user defined types? Any way to keep business logic out of the system, or
: least make things more transparent and easy to maintain?
|
s**********o
发帖数: 14359 | 3 3 NORMAL FORM的数据库用起来就是这样的，JOIN JOIN JOIN，一大堆的BUSINESS
LOGIC在SP里，这还是好的了，
如果在APPLICATION里就惨了，找都找不出来。其实好多
复杂的报表需要DATAWAREHOUSE或者SUMMARY TABLES，
事先ROLL好了，REPORT直接DISPLAY好了，CALL 很多很复杂的SP会很慢。 |
n****n
发帖数: 59 | 4 好吧，我看来不是第一个也不是最后一个被搞疯掉的。感觉版上的好多dba们挺轻松的
，所以猜他们的系统设计和实现一定很好， 不用像我们一样今天擦昨天的屁股，明天
擦今天的。。。 |
W*******e
发帖数: 1268 | 5 要想成擦财神爷的屁股就不郁闷了
【在 n****n 的大作中提到】
: 好吧，我看来不是第一个也不是最后一个被搞疯掉的。感觉版上的好多dba们挺轻松的
: ，所以猜他们的系统设计和实现一定很好， 不用像我们一样今天擦昨天的屁股，明天
: 擦今天的。。。
|
s**********o
发帖数: 14359 | 6 DBA应该会分析DEVELOPER的STORED PROCEDURE，有经验的DBA很快就能分析出SLOW
PERFORMANCE的问题或者为什么出错，但也有很多大公司的DBA，对DATA MODEL一窍不通
，作为DBA，如果有时间要了解自己的数据，比DEVELOPER强，才能立足不败之地，也会
成为公司财富的一部分。
【在 W*******e 的大作中提到】
: 要想成擦财神爷的屁股就不郁闷了
|
y****w
发帖数: 3747 | 7 我这儿花了一年多把事儿整理的差不多了，原先是成天这事儿那事儿不停，现在我要消
失一星期也没关系。
bad thing is, 从此俺就不重要了，有好事儿人家不想着你了。所以，俺要走了。
【在 n****n 的大作中提到】
: The current system in my company drives me crazy. There are just too many
: stored procedures and many business logic are hard coded in them. So I
: wonder how you guys set up and maintain database, and what is the best
: practice in industry. Should we use more generic sprocs, dynamic sqls more
: user defined types? Any way to keep business logic out of the system, or
: least make things more transparent and easy to maintain?
|
e******n
发帖数: 3435 | 8 stored proc有时候是必须的，为了性能，必须写在数据库层。
【在 n****n 的大作中提到】
: The current system in my company drives me crazy. There are just too many
: stored procedures and many business logic are hard coded in them. So I
: wonder how you guys set up and maintain database, and what is the best
: practice in industry. Should we use more generic sprocs, dynamic sqls more
: user defined types? Any way to keep business logic out of the system, or
: least make things more transparent and easy to maintain?
|
s**********o
发帖数: 14359 | 9 是的，最好不要把复杂的QUERY写在APPLICATION里，一旦PERFORMANCE出了问题，很难
处理。我搞开发尽量利用数据库的功能完成数据的处理和BUSINESS LOGIC，
APPLICATION只是DISPLAY一下
【在 e******n 的大作中提到】
: stored proc有时候是必须的，为了性能，必须写在数据库层。
|
y****w
发帖数: 3747 | 10 tom kyte好像说过，要是你就只用最简单的数据存储查询功能，花那么多钱买oracle干
嘛.. --- 而且那本书还是面对developer的，所以还不能说他在指replication/ha/dr
之类的玩意儿。
【在 s**********o 的大作中提到】
: 是的，最好不要把复杂的QUERY写在APPLICATION里，一旦PERFORMANCE出了问题，很难
: 处理。我搞开发尽量利用数据库的功能完成数据的处理和BUSINESS LOGIC，
: APPLICATION只是DISPLAY一下
|
|
|
n****n
发帖数: 59 | 11 好的程序员是懒程序员，好的DBA是无所事事的DBA，但关键是好老板要知道谁是好的程
序员和DBA。
【在 y****w 的大作中提到】
: 我这儿花了一年多把事儿整理的差不多了，原先是成天这事儿那事儿不停，现在我要消
: 失一星期也没关系。
: bad thing is, 从此俺就不重要了，有好事儿人家不想着你了。所以，俺要走了。
|
n****n
发帖数: 59 | 12 大侠给指条路吧，如果要学您这功夫要看什么方面的书，有没有一个书单。
我道行浅只看过一点入门的query的书，但觉得现在的db太混乱太痛苦了，每天都是
data cleansing其他事都干不了了
【在 y****w 的大作中提到】
: 我这儿花了一年多把事儿整理的差不多了，原先是成天这事儿那事儿不停，现在我要消
: 失一星期也没关系。
: bad thing is, 从此俺就不重要了，有好事儿人家不想着你了。所以，俺要走了。
|
n****n
发帖数: 59 | 13 是不是不同的数据库，用途不一样，设计思路也不会一样呢？如果是企业内部管理方面
的，像你说的应该比较好。我们这主要是拿别人的数据做data cleansing，然后集成到
自己的db里，再做一些计算。本来用db来做data cleansing听着挺好，问题是很多
special cases，搞得很多计算结果都有问题，然后又得去找query，debug...然后像
query这样的script一样的东西一多，就很难管理。5，6个developer，成百上千的
queries，就像一场灾难...
有没有可能在数据库里用更generic的设计，使得business logic集中管理，debug/
tracing calculation（有点像excel的tracing dependent）更方便？还是说这样的应
用放在application里会更好？
【在 s**********o 的大作中提到】
: 是的，最好不要把复杂的QUERY写在APPLICATION里，一旦PERFORMANCE出了问题，很难
: 处理。我搞开发尽量利用数据库的功能完成数据的处理和BUSINESS LOGIC，
: APPLICATION只是DISPLAY一下
|
W*******e
发帖数: 1268 | 14 the design may vary on your applications:
transaction oriented
data-collection oriented
business process/behavior/flow oriented
BI oriented
decision-making oriented
etc
【在 n****n 的大作中提到】
: 是不是不同的数据库，用途不一样，设计思路也不会一样呢？如果是企业内部管理方面
: 的，像你说的应该比较好。我们这主要是拿别人的数据做data cleansing，然后集成到
: 自己的db里，再做一些计算。本来用db来做data cleansing听着挺好，问题是很多
: special cases，搞得很多计算结果都有问题，然后又得去找query，debug...然后像
: query这样的script一样的东西一多，就很难管理。5，6个developer，成百上千的
: queries，就像一场灾难...
: 有没有可能在数据库里用更generic的设计，使得business logic集中管理，debug/
: tracing calculation（有点像excel的tracing dependent）更方便？还是说这样的应
: 用放在application里会更好？
|
B*****g
发帖数: 34098 | 15 要招人吗？哈哈
【在 n****n 的大作中提到】
: The current system in my company drives me crazy. There are just too many
: stored procedures and many business logic are hard coded in them. So I
: wonder how you guys set up and maintain database, and what is the best
: practice in industry. Should we use more generic sprocs, dynamic sqls more
: user defined types? Any way to keep business logic out of the system, or
: least make things more transparent and easy to maintain?
|
y****w
发帖数: 3747 | 16 感觉是个管理问题而不是技术问题，这是项目architect的事儿啊？ 说白了还是没太明
白你到底痛苦在哪儿了，你的环境是麻烦，如果你能具体说说现在是什么样子，你想做
什么做不了之类就好多了。
你前面好像说到用动态语句之类，我没搞清楚这个的需求。动态语句多很多灵活性，比
如可以让schema也变化起来；但一般代价sp代码的可读性。
本来用db来做data cleansing听着挺好，问题是很多
special cases，搞得很多计算结果都有问题，然后又得去找query，debug...然后像
query这样的script一样的东西一多，就很难管理。5，6个developer，成百上千的
queries，就像一场灾难...
有没有可能在数据库里用更generic的设计，使得business logic集中管理，debug/
tracing calculation（有点像excel的tracing dependent）更方便？还是说这样的应
用放在application里会更好？
【在 n****n 的大作中提到】
: 是不是不同的数据库，用途不一样，设计思路也不会一样呢？如果是企业内部管理方面
: 的，像你说的应该比较好。我们这主要是拿别人的数据做data cleansing，然后集成到
: 自己的db里，再做一些计算。本来用db来做data cleansing听着挺好，问题是很多
: special cases，搞得很多计算结果都有问题，然后又得去找query，debug...然后像
: query这样的script一样的东西一多，就很难管理。5，6个developer，成百上千的
: queries，就像一场灾难...
: 有没有可能在数据库里用更generic的设计，使得business logic集中管理，debug/
: tracing calculation（有点像excel的tracing dependent）更方便？还是说这样的应
: 用放在application里会更好？
|
n****n
发帖数: 59 | 17 这正是我所猜想的。请螃蟹大侠明示，愿闻其详。不好意思我唯一见过的另一个
database是northwind.
【在 W*******e 的大作中提到】
: the design may vary on your applications:
: transaction oriented
: data-collection oriented
: business process/behavior/flow oriented
: BI oriented
: decision-making oriented
: etc
|
s**********o
发帖数: 14359 | 18 要想看懂别人的QUERY和SP，很重要的一点就是要把DATA MODEL搞清楚，没有MODEL，可
以做个REVERSE ENGINEERING看看TABLE之间的关系，关系搞清楚了，
SP的目的的搞清楚，看起CODE就比较容易了。 |
y****w
发帖数: 3747 | 19 看来你只是还不熟悉工作环境阿。多花点时间，理清楚什么都是干什么的，后面就好多
了。
【在 n****n 的大作中提到】
: 这正是我所猜想的。请螃蟹大侠明示，愿闻其详。不好意思我唯一见过的另一个
: database是northwind.
|
p********l
发帖数: 279 | 20 You have to consider Job Security. That's one thing I learned.
【在 y****w 的大作中提到】
: 我这儿花了一年多把事儿整理的差不多了，原先是成天这事儿那事儿不停，现在我要消
: 失一星期也没关系。
: bad thing is, 从此俺就不重要了，有好事儿人家不想着你了。所以，俺要走了。
|
|
|
p********l
发帖数: 279 | 21 You have to consider Job Security. That's one thing I learned.
【在 y****w 的大作中提到】
: 我这儿花了一年多把事儿整理的差不多了，原先是成天这事儿那事儿不停，现在我要消
: 失一星期也没关系。
: bad thing is, 从此俺就不重要了，有好事儿人家不想着你了。所以，俺要走了。
|
n****n
发帖数: 59 | 22 具体说，我们这个系统主要做数据存储和简单的加工（derived data），下游还有进一
步的数据分析。metadata/standing data不复杂，所以不是太麻烦。经常碰到的问题主
要是：
1.比如说外来的数据有变量（column）a， b， c...，我们自己的变量本来是x=a+b，
y=c*d...，但后来对数据有更多的理解，要该成case1 x=a+b， case2 x=a+e。这些逻
辑变化几乎每天都有。此外还有data cleansing的逻辑也很多，也经常要修改。现在都
是hard code到sp里。比较难维护。
2.不时会有data feed或者process failure，在下游发现错误，需要追溯问题源头。也
很花时间。
痛苦就是本来想着数据库比较方便，但实际上每天维护数据就耗费大量时间。
【在 y****w 的大作中提到】
: 感觉是个管理问题而不是技术问题，这是项目architect的事儿啊？ 说白了还是没太明
: 白你到底痛苦在哪儿了，你的环境是麻烦，如果你能具体说说现在是什么样子，你想做
: 什么做不了之类就好多了。
: 你前面好像说到用动态语句之类，我没搞清楚这个的需求。动态语句多很多灵活性，比
: 如可以让schema也变化起来；但一般代价sp代码的可读性。
:
: 本来用db来做data cleansing听着挺好，问题是很多
: special cases，搞得很多计算结果都有问题，然后又得去找query，debug...然后像
: query这样的script一样的东西一多，就很难管理。5，6个developer，成百上千的
: queries，就像一场灾难...
|
W*******e
发帖数: 1268 | 23 如果数据逻辑很混乱应该先把逻辑整理清楚，不然以后可能还要不停的修改。
如果上游数据不一致，比如你用一个标准的metadata规范去读上游数据，而源数据都使
用自己的metadata规范，这种情况可以考虑中间加一层数据映射。以后上游数据格式变
了，简单的变化可以修改mapping表，复杂的变化也只需要重写某一类的数据。
，
【在 n****n 的大作中提到】
: 具体说，我们这个系统主要做数据存储和简单的加工（derived data），下游还有进一
: 步的数据分析。metadata/standing data不复杂，所以不是太麻烦。经常碰到的问题主
: 要是：
: 1.比如说外来的数据有变量（column）a， b， c...，我们自己的变量本来是x=a+b，
: y=c*d...，但后来对数据有更多的理解，要该成case1 x=a+b， case2 x=a+e。这些逻
: 辑变化几乎每天都有。此外还有data cleansing的逻辑也很多，也经常要修改。现在都
: 是hard code到sp里。比较难维护。
: 2.不时会有data feed或者process failure，在下游发现错误，需要追溯问题源头。也
: 很花时间。
: 痛苦就是本来想着数据库比较方便，但实际上每天维护数据就耗费大量时间。
|
y****w
发帖数: 3747 | 24 re楼上．
这个问题不是数据库问题，就是放到外面也一样存在．将规则(meta data)和实际执行
分开是个好主意．这也许是你前面说到用＂动态＂sql的原因？看复杂程度不同，也许
一个简单的mapping就可以，也许你的规则会复杂到不能嵌套到sql里面的程度，这时候
你需要的是exit SP；更复杂的情况也有．．． 最后，ｏｋ，恭喜你们，你们完成了
一个小型的ETL软件。
还有你需要考虑的是规则变了怎样去改变已有数据。
这绝对是个architect问题。那边脑子不清楚，这边dba/developer累死也白搭。
，
【在 n****n 的大作中提到】
: 具体说，我们这个系统主要做数据存储和简单的加工（derived data），下游还有进一
: 步的数据分析。metadata/standing data不复杂，所以不是太麻烦。经常碰到的问题主
: 要是：
: 1.比如说外来的数据有变量（column）a， b， c...，我们自己的变量本来是x=a+b，
: y=c*d...，但后来对数据有更多的理解，要该成case1 x=a+b， case2 x=a+e。这些逻
: 辑变化几乎每天都有。此外还有data cleansing的逻辑也很多，也经常要修改。现在都
: 是hard code到sp里。比较难维护。
: 2.不时会有data feed或者process failure，在下游发现错误，需要追溯问题源头。也
: 很花时间。
: 痛苦就是本来想着数据库比较方便，但实际上每天维护数据就耗费大量时间。
|
n****n
发帖数: 59 | 25 多谢云兄螃兄指点。逻辑的变化可能没法避免，主要是源于一对源数据有更多理解（数
据源本身直接sync我们的table，没有太多变化。是我们自己的认识在变化。当然偶尔
会有错误数据，这也是另一个要trace back的原因）；二自己的business logic的慢慢
积累。确实像你们所说，简单的就用mapping解决；但一旦复杂起来，通常就是join一
堆，情况A，情况B...所以感到放在sp里很不方便。我去看看ETL是怎么做的。
俺们小庙没有好architect，一堆半路出家的和尚。前面beijing妹妹逗笑问招人不，唉
我看还是少俩个更好。 |
B*****g
发帖数: 34098 | 26 ETL技术上没啥，设计好了不易。如果太不灵活，一个改动要改几十个processes，小改
动光测试就得半年。设计好了就几个processes，改动测试都很容易。在这方面俺经验
还是很足的，包括怎么设计sp更灵活，小菜。所以我们整组人整天没事做，别人还以为
我们很忙，成果很大，哈哈
【在 n****n 的大作中提到】
: 多谢云兄螃兄指点。逻辑的变化可能没法避免，主要是源于一对源数据有更多理解（数
: 据源本身直接sync我们的table，没有太多变化。是我们自己的认识在变化。当然偶尔
: 会有错误数据，这也是另一个要trace back的原因）；二自己的business logic的慢慢
: 积累。确实像你们所说，简单的就用mapping解决；但一旦复杂起来，通常就是join一
: 堆，情况A，情况B...所以感到放在sp里很不方便。我去看看ETL是怎么做的。
: 俺们小庙没有好architect，一堆半路出家的和尚。前面beijing妹妹逗笑问招人不，唉
: 我看还是少俩个更好。
|
W*******e
发帖数: 1268 | 27 BSO，发包子
【在 B*****g 的大作中提到】
: ETL技术上没啥，设计好了不易。如果太不灵活，一个改动要改几十个processes，小改
: 动光测试就得半年。设计好了就几个processes，改动测试都很容易。在这方面俺经验
: 还是很足的，包括怎么设计sp更灵活，小菜。所以我们整组人整天没事做，别人还以为
: 我们很忙，成果很大，哈哈
|
y****w
发帖数: 3747 | 28 没用的。 要不你骂骂伊，
【在 W*******e 的大作中提到】
: BSO，发包子
|
n****n
发帖数: 59 | 29 其实我想这也是个经验活，我临时去看也只是看点皮毛。有没有tips，mm zkss。
【在 B*****g 的大作中提到】
: ETL技术上没啥，设计好了不易。如果太不灵活，一个改动要改几十个processes，小改
: 动光测试就得半年。设计好了就几个processes，改动测试都很容易。在这方面俺经验
: 还是很足的，包括怎么设计sp更灵活，小菜。所以我们整组人整天没事做，别人还以为
: 我们很忙，成果很大，哈哈
|
