太同情你了，换我就只能糊弄过去，然后再弄个相似项目把东西顶上去。
这玩意就不能给不熟悉的人弄，要不容易把自己栽进去。
以后撒项目时候可得小心。
【 在 Alfard 的大作中提到: 】
: 我告诉她怎么干，任务就完工了，复杂性工作，知道怎么干就是任务本身。割麦子告诉她怎么割，她可以再割十亩。写标准写方案告诉她怎么写，那她就剩下敲字了，我还要研究团队干啥？招个打字员就好了嘛。这种求告知怎么干的，表面上态度谦虚，实际上就是责任上交，逃避矛盾。而且你真的在告诉她哪里不合适要求改的时候，他又会有一百个理由等着反驳你。
:
: 其实就是写一个数据库命名标准而已，工作量很小，三五页纸，就是吃经验吃认识。但是规范要考虑整个组织数据架构，数据库治理方式，要从它们生成这个规范，虽然我们现在统一的数据治理很欠缺，但是如果知道方法论，也不影响做出命名的规则。关于我不指导的问题，我10年前做软件的，复杂度都在繁杂的业务上，几乎没有性能要求，也有dba建库，所以不太用关心数据库原理机制。但是规范要考虑开发、数据工程师、dba、数据治理人员等等很多角色使用的舒适性，这些角色的工作很多我没接触过，现在做科研管理岗也不现实再回过头去了解，就没法告知编写组答案。编写组都是技术小白，写这个想当然，不是从技术角度出发的，写的规则都搞笑。一开始我让他们让贤，寻找个对数据有心得的大牛小牛，把编写排名让给他，其他人排后，大姐说找不到继续自己努力，我又让大姐咨询这几个角色，看看他们日常工作有什么内容，哪些跟命名相关。大姐找了本单位的相关角色，问完只带回两句话，dba说他用不到数据库内部的元素，数据工程师说表是原样发给某数据中台的，over。这期间还有很多沟通内容，劲头差不多，让我对团队技术无能的认识一次次印证。
:
: 发帖期间我已经把Oracle机制大概搞清楚了，现在正在看MySQL，我也是被逼得无奈了。
:
: 【 在 feitonfeiton 的大作中提
: : 报告不重要
: : 包装汇报吹牛皮才重要，私企的话老老实实找行家把技术干完。G
: : 企的话 要么凑合接受，要么打到重新来
: : ...................
:
: --
--
FROM 120.245.0.*