小编Tim*_*Tim的帖子

我更喜欢编码标准是合乎逻辑的.这是我为什么以下一套标准没有的论点.

我需要知道以下两件事之一:(1)为什么我错了,或者(2)如何说服我的团队改变它们.

camelCase:函数,类名,方法和变量必须是camelCase.

• 难以区分变量和类
• 针对PHP的小写/下划线变量/函数和UpperCamelCase类

例:

$customerServiceBillingInstance = new customerServiceBillingInstance(); // theirs
$customer_service_billing_instance = new CustomerServiceBillingInstance();

函数/方法必须始终返回一个值(并且必须始终存储返回的值).

这出现在我们的数百个php页面上:

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase(true, '');
$success = $equipmentList->setCustomerList();
$success = $equipmentList->setServerList();
$success = $equipmentList->setObjectList();
$success = $equipmentList->setOwnerList();
$success = $equipmentList->setAccessList();

返回值很少使用,但始终存储.它鼓励使用复制粘贴.

没有静态方法

类似下面的行在代码库中出现了数千次:

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase();

我会比较喜欢:

$equipmentList = equipmentList::load();

有什么理由不使用静态方法或属性？不是静态方法负责非特定于实例的逻辑吗？像初始化或填充新实例一样？

除非一切都返回一个对象,否则您的代码不是OOP

有一段代码执行查询,检查几种错误方式,然后处理生成的数组.它被重复(复制+粘贴)几次,所以我把它放在基类中.然后我被告知返回一个数组不是OOP.

你如何捍卫这些做法？我真的需要知道.我觉得我正在服用疯狂的药片.

如果你不能为他们辩护,你如何说服他们需要改变的坚定作者？

目标

找到一个完美,灵活的模式,用于存储许多不同类型的对象,在关系数据库中它们之间具有各种各样的链接.

问题

EAV是RDBMS正常限制的一种解决方法.

如果你要规范化EAV架构,那将是丑陋的.

理念

如果EAV正常化,那将是丑陋的.

我们传统上手工维护这些架构的事实是否限制了它们的复杂性和功能？

但如果以编程方式维护和查询,那有什么关系呢？

图表

如果n在n不同的表中有不同的实体,为什么不让代码生成n(n+1)/2链接表以及它们之间的查询？这不会导致规范化架构中的真实图形吗？

在高度相互关联的数据库中,总是会有比指数更多的边缘.为什么不专注于创建正确的标准化Verticle(n实体表)并让我们的代码保持边缘(n^x链接表)？

结论

系统能否规范化EAV并维护最终的复杂模式？

复杂的图形可以存储在(并保持真实)关系数据库中吗？

我确信之前已经完成了,但我从未见过它.我错过了什么？

示例问题

存储印刷品及其书目数据

• 许多属性可能不仅仅是字符串而是整个对象.
• 在库世界中,没有简单(和关系)模式可以在没有极其复杂的模式的情况下"无损地"存储数据.
• 许多不同类型的关联和关联对象
  • 及其相关属性(可能会有很大差异).
  • 他们之间有许多不同类型的关系.

问题

" 你想解决什么问题？ " -
皮特

我正在寻找关系数据库系统中EAV,图形和多态关系的规范化解决方案.

" 我不愿意成为那些在投入生产后必须理解或维护它的人. " -
安德鲁

这种"传统维护"正是我所说的应该是自动化的.这不是很大的咕噜声吗？