这是一个创建于 3625 天前的主题，其中的信息可能已经有所发展或是发生改变。
MySQL数据库。
PHP项目。
项目有用ORM也有执行原生SQL。数据库访问都是基于Zend Db组件。
我尝试写了个SQLParser来替换SQL语句中的表名和字段名，但是因为SELECT * 的关系，返回数据集的字段名没法替换掉。
有没有什么好办法可以尽可能少修改代码来实现，有没有可能在数据库上动手脚？
PHP项目。
项目有用ORM也有执行原生SQL。数据库访问都是基于Zend Db组件。
我尝试写了个SQLParser来替换SQL语句中的表名和字段名，但是因为SELECT * 的关系，返回数据集的字段名没法替换掉。
有没有什么好办法可以尽可能少修改代码来实现，有没有可能在数据库上动手脚？
 |
1
raincious 2014-12-19 13:44:07 +08:00 via Android
第一步怎么不是禁止ORM执行原生SQL？禁了这个其他都好办。
另外SELECT *也不是最佳操作吧？ |
 |
3
tabris17 OP 现在的问题是不符合DDL规范的表，运维部门不给部署到生产服。现在的目的只要能骗过运维部让项目上线就行
|
 |
4
88250 2014-12-19 13:50:18 +08:00
花点时间改呗....
|
 |
5
66450146 2014-12-19 13:55:11 +08:00  1
:%s/_/UNDERSCORE/g
|
|
6
66450146 2014-12-19 13:55:35 +08:00
千万不要真的这么做……
|
 |
8
xiaogui 2014-12-19 14:00:14 +08:00
为什么禁止下划线？那你们用什么分词？
|
 |
12
wesley 2014-12-19 14:06:56 +08:00
给运维不熟的数据库里只放几个假表，部署完之后，在服务器上放个phpmyadmin，把真正的表导进去
|
 |
13
nicai000 2014-12-19 14:07:37 +08:00
规范应该先于代码啊....
|
 |
16
dorentus 2014-12-19 14:09:08 +08:00 via iPhone 1
话说，Google 的各种语言的代码规范里面，大都会提到旧代码如果不符合规范该怎么办，其中一个很重要的原则就是不要*仅仅*去为了让代码符合规范而去改。
所以在我看来这要求的确有点神经病了… 没啥特别省事的方法了，也就是修改-单元测试如此循环，该多少工作量就上报多少工作量吧。如果有什么来不及，那责任肯定不在开发这边。 |
|
17
xiaogui 2014-12-19 14:12:07 +08:00
@tabris17 那就把修改这个需要的真实时间 * 2.5 提交给你的上级，然后列出因为要做这个所谓的规范，然后目前其他所有项目完全停工。
|
 |
19
cloudzhou 2014-12-19 14:14:25 +08:00
使用下划线有任何问题吗？我不理解，一直依赖我们都是使用下划线作为分隔符号。
|
 |
24
wdd2007 2014-12-19 14:22:41 +08:00
你是上级。。。你需要有能力拒绝这个要求。。。
|
|
27
xiaogui 2014-12-19 14:27:26 +08:00
@tabris17 加班的话，也会影响其他项目的进度，把这些都弄清。你肯定是要向上面汇报这样造成的后果。
另测试部可以提功能需求，任何人都可以。但是研发部要有自己的开发计划，以及预估出其他人提的需求需要的开发时间和重要性，结合实际情况，然后同意、拒绝或者放入需求池等等。 |
|
28
tabris17 OP @xiaogui 测试提需求的意思如果不实现这个功能就认为是程序BUG不让过测试，另外测试直接和开发提，当产品经理死了吗
|
 |
29
ls25145 2014-12-19 14:34:03 +08:00
这个必须反映一下，不管上面是不是管技术的。
代码先写的，规范后定的。明显是运维的问题，这个要是不强硬对待，以后有的是办法收拾你。 要么延期，要么无视这个规范。 |
|
30
xiaogui 2014-12-19 14:35:34 +08:00
@tabris17 按这样的话，就只能拖着了，嗯。加班的时候记着拉上测试，随时让他们测试。
另如果你是研发部门的头的话，你是有权力去拒绝任何你感觉不对的研发需求，规范，并参与对这些需求的谈论，规范的制定中的。否则的话，相信我，你们研发部估计是这公司最苦逼的部门，注意部门小伙伴们可能会陆续离开。 |
|
32
raincious 2014-12-19 14:37:49 +08:00
@tabris17 如果仅仅是想刷存在感：
1、查一下你拿到手的需求以及之前所有的Note，看看运维在开发之前有没有提出规范限定，如果有，但是你的团队没遵守，那就是你的问题，如果没有，那就是没有必要遵守。 2、如果之前没有提出，上线时临门一脚，你直接说明原因和后果报给Boss让他解决这个问题好了。 其实作为Leader有的时候需要问一下各部门的，比如各种规范什么的，只需要一句话就能解决很多问题。 3、运维竟然以非关键（且未知会过）的原因阻止项目上线，这你必须和Boss谈下，了解和规范下他们的权利。 |
|
33
tabris17 OP 我觉得有点跑题了，咱们还是回到技术问题上来好吗
|
|
34
raincious 2014-12-19 14:43:54 +08:00
@tabris17
如果你真的要这么做，那就一点点修改代码，改成符合运维要求的 > 我尝试写了个SQLParser来替换SQL语句中的表名和字段名，但是因为SELECT * 的关系，返回数据集的字段名没法替换掉。 不要这么玩，增加了复杂度和不确定性。未来维护会非常麻烦。 |
|
35
xiaogui 2014-12-19 14:46:05 +08:00
快速替换的方法，有任何后果是需要你承担的。
|
 |
36
skybr 2014-12-19 14:46:14 +08:00 1
我在想, 写django或者rails的没下划线怎么活
|
 |
37
cloudzhy 2014-12-19 14:53:02 +08:00 1
蛇形法明显比驼峰法更容易一眼看出来。
|
|
38
tabris17 OP 1
@skybr 还真被你说中，手头还有个django项目，我准备到时候用ansible playbook自动部署，他们运维不懂的话也就闭嘴了。
|
 |
39
shadyxu 2014-12-19 15:19:24 +08:00
“管不到其他部门”，其他部门当然不能管，沟通，沟通不了就向上反馈让上面决定。“不想得罪运维”，就不怕得罪自己组的人？
作为一个leader，跨部门合作怎么能这么被动。这个就不应该是技术问题，无厘头的要求就必须说no。 |
|
40
tabris17 OP 1
|
|
41
shadyxu 2014-12-19 15:21:51 +08:00
LZ你就想想，你自己都这么排斥，你的组员，也就是最后真正去改的人，会是什么想法。如果这种没来由且滞后还又跨部门的要求你都直接妥协，你的组员会怎么想你。
|
|
42
shadyxu 2014-12-19 15:29:28 +08:00
@tabris17 不仅仅是这次上线的问题，你们以前的项目也全部要改吗，新项目以后也要这样吗。既然你管不动跨部门的运维，那他们跨部门给你们提的要求你怎么就直接接受了。这种你觉得不对的东西，还要折腾耗费工作量，又会引起组员反感，这都不去据理力争，别人还能指望你什么。
|
|
43
tabris17 OP @shadyxu
规范和项目在我来公司之前就都存在了，是当时负责的开发没有留意规范，而项目一直没上线，所以直到最近要上线前才发现不符合规范的问题（当然这个规范有多傻逼就不提了），所以我没找开发算账已经不错了，开发还反感个毛啊。 |
 |
44
aru 2014-12-19 16:13:30 +08:00
老老实实改代码，或者去掉这个规划
|
 |
46
loryyang 2014-12-19 16:20:21 +08:00
这，你作为技术总负责人居然没有怼回去？难道你们那边rd还不如运维强势？
要是我我就给他排期排个三个月，给他慢慢改。上头要是对我有意见，老子拍拍屁股走人，哪儿不是一样干，干这样傻逼的事情，还不如不干 你就这样想，你这么干对得起手下的弟兄吗？ |
 |
47
dingyaguang117 2014-12-19 16:22:04 +08:00
表明字段名有下划线 有啥缺点呢
|
 |
48
loveyu 2014-12-19 16:33:19 +08:00
我咋觉得下划线明显比那个驼峰好区分
|
 |
49
sunhk25 2014-12-19 16:35:17 +08:00
用的cakephp，官方文档，例子里面的表名，字段名全都是下划线来标识的。。。
|
|
50
tabris17 OP 2
@dingyaguang117 完全没有，反而是驼峰法会有问题，在不同系统下，mysql表名大小写敏感是不一样的。
|
 |
51
akira 2014-12-19 16:36:11 +08:00
按照你说的话，规范应该是一直存在的，老老实实的改代码吧，别取巧。
|
 |
52
akfish 2014-12-19 16:40:29 +08:00
这种事情运维也来指手画脚？真是醉了。
|
 |
53
kaneg 2014-12-19 16:47:19 +08:00
这就是软件开发中的蝴蝶效应。
|
 |
54
edwardtoday 2014-12-19 16:47:46 +08:00
这个月刚把原先驼峰命名的MySQL表名改成全小写用下划线分词。
开发环境MySQL是跑在linux上的，一直没问题。 直到在某台Windows上装了MySQL，发现默认不区分大小写表名，真是悲伤。 我不知道你们是否会遇到跨平台的问题，但是就表名而言，你们新来的话事人是不是还要把 information_schema 改成 InformationSchema 呢？问问MySQL同不同意？？ 规范不对的时候改规范。规范不合理的时候，争取改合理了。忍气吞声埋头做，出问题谁负责？延期谁负责？责任都你团队负，权利都在其他部门，这不搞笑呢么。玩不转的。 |
|
55
tabris17 OP 1
@edwardtoday 本地开发环境是windows的，不过以后项目我会让他们都在vagrant虚拟机上开发。
定这个规范绝对是人绝对是脑子进大便了，没办法 |
 |
56
evlos 2014-12-19 17:14:54 +08:00 via iPhone
卧槽 表名还不让用下划线了 哪个逗比定的规范。。。
|
|
57
cloudzhou 2014-12-19 17:37:04 +08:00
@tabris17 让运维发出邮件，详细列出这样做的目的、好处。并且表示，出于xxx的原因，如果没能说服这样修改的合理性，将不做这样的更改。
|
 |
58
aa88kk 2014-12-19 18:08:45 +08:00
你们公司运维是个大5B, mysql默认的命名方式就是小写加下划线，查询是不区分大小写的。所以大小写只会在显示上有区别。你们公司也奇葩，运维能管这个？ 换个公司吧。
|
 |
59
huigeer 2014-12-19 18:09:28 +08:00
别人吃大便就让他吃， 用不着赔他吃，
|
 |
60
zzColin 2014-12-19 18:29:05 +08:00
显然楼主措辞上有点问题，以致于几乎所有回复都当成是运维故意找茬了，但不管规定再怎么脑残，楼主显然已经在 43 楼承认了是自己和手下开发人员的疏忽
|
 |
61
cdxem713 2014-12-19 18:44:43 +08:00 via iPhone
我记得sql是大小写不敏感的啊
|
 |
62
dong3580 2014-12-19 19:44:19 +08:00
|
 |
63
jjx 2014-12-19 20:00:02 +08:00 1
你这当领导真没有领导的能力, 这种事情要是我,直接就顶回去,顶到最高层, 大不了不干了,如果公司同意这种sb做法,这种公司有什么留的必要
|
 |
65
mhycy 2014-12-19 20:12:09 +08:00
说起来 这个规范真的是脑子被夹了....
SQL的保留字符统统大写,表名,字段名小写+下划线在调试的时候容易看很多..... |
 |
66
lincanbin 2014-12-19 20:31:41 +08:00
运维脑子进水了，代码规范应该由开发团队自己制定，运维手伸这么长干嘛？
|
 |
67
billwang 2014-12-19 21:46:49 +08:00
DDL，让我想起来灾备了，赶紧把检修期间注意的记了下来。
|
 |
69
kurtis 2014-12-20 00:57:41 +08:00 1
下次运维规定你们不许用大拇指以外的手指来按空格，不许你们打字时看键盘，因为都违反指法规范。
若是发现，一次警告，两次剁手指，三次挖眼珠。 运维在给你下马威呢，强烈不推荐留在这样的公司，以后玩政治会很厉害的。 |
 |
70
revlis7 2014-12-20 01:49:26 +08:00
看了半天，我突然明白了，这就是传说中真真正正的DevOps啊
|
 |
71
wy315700 2014-12-20 09:43:21 +08:00
|
Select Language