我一直认为SELECT *很糟糕，你应该总是只返回你要使用的列。其中一个原因是，如果所需的所有列都在索引中，则DB可以返回结果而不会访问任何表。
我有一个加载Product对象属性的工厂类。每次调用GetProduct等时都会加载所有属性。
许多页面都不会使用所有的产品属性，即使它们会因为SELECT *而从数据库加载。
有没有关于此的设计建议/指南？
答案 0 :(得分：3)
这里的权衡取决于每个最后一点潜在性能与代码可维护性之间的差异。毫无疑问，恢复不使用的列会浪费一些CPU周期。问题变成：有多少？那么你必须考虑更昂贵的，浪费的CPU周期或程序员构建和维护代码的时间？
如果您正在处理具有巨大性能要求的系统，那么优化您的ORM /工厂代码可能会非常有用。另一方面，如果你正在构建一个部门业务应用程序并且你有几十个或几百个ORM课程，那么你最好还是让程序员（以及那些需要付费的人）保持简单并且不要担心几个周期。如果您使用一个框架来支持代码生成的大部分ORM代码（例如Entity Framework（或许多其他代码）），情况就更是如此......
如果您在不使用任何类型的代码生成框架的情况下构建系统，并且如果您的数据访问层非常接近裸机SQL，那么只返回您需要的是好建议。如果您正在构建一个同时被数千或数百万人使用的应用程序，那么请务必从一开始就调整SQL。另一方面，如果您在使用ORM框架和RAD或敏捷的商店工作，那么编写数十个SQL会产生相反的效果。
答案 1 :(得分：0)
我绝对会避免SELECT *。只需检索您知道您需要的数据。我更喜欢在同一个表中写入十几个查询，其中每个查询只引用我为特定目的所需的几个列，而不是编写一个检索所有列的查询，只是在任何地方使用它。
即使您知道需要当前表中的每一列，也要明确列出每一列。这样，如果将来有人将六个列添加到表中，那么所有旧查询都不会突然检索到超出需要的数据。