如果你是设计师，在产品设计上，永远要相信自己是专家，千万不要因为客户委托你们做这个项目而把客户的每一句话当做金科玉律，然后受到干扰而不断按照客户的想法设计。那样是你的失职！如果产品失败，最后客户一句“你是专家！”你当如何？
如果客户是专家，那又为何让你设计？ 如果客户不是专家，那为何他又要充当设计师呢？ 所以，请大胆的说"No！" 在产品上，旁人总是指手画脚的，因为这样他可以显示他的存在，可你却不能随意更改设计的。 始终记住，每个产品设计都有其设计哲学和气质，这个气质是由设计师的气质所主导的。 在他人的干扰下，特别是气质和设计师不相符甚至背道而驰、或者不是设计方面专家的人的观点就左右了你，那么你的产品也将变成一个没有特点的、气质全无的产品。
你会喜欢一个没有气质的女孩吗？ 不知道你会不会，反正我不会的:)
我们的产品只期望能满足一部分客户的需求，不期望所有。如果那部分客户不能认同我们的设计理念，那么就不要考虑发展他成为我们客户，更不要因为这部分客户改变我们的设计理念。
在我们的一些应用中，我们可能不能完全设想到用户需要什么样的属性。比如给你一个用户个人信息记录页面，你可能能想到常用的信息，比如
| 用户名 | xxxxx |
| 邮箱 | xxxx@xxxxx.com |
| 电话 | 13xxxxxxxxx |
但后来用户发现，他可能想记录下自己工作的地址，这样可以方便别人找到自己，那怎么办呢？我们系统开始没有设计这个属性呢。这时候，我们就需要一种方案来轻松的让用户扩展属性。目前gmail的联系人里面就有这个功能。我们的扩展不能去修改原来的表结构，那样不安全，而且由于每个人的需求不一样，很难做到满足大众的个性化需求。这样，我们可以设计一个表来专门支持属性扩展。
我们设计的表 结构如下，（oracle）
create table C_Dic
(
/* 主键 */
id Integer not null,
/* 表名 */
tableName varchar2(50) null,
/* 所扩展表的主键，可以两种格式存储，json和索引算法。
json 格式简单，易读，但查询效率较低，索引算法生成的串不可读
，
但效率较高。 比如， md5(table+ k1 + k2)
*/
"key" varchar2(254) null,
/* 所扩展表最原始的可以值。json格式。 */
keys varchar2(254) null,
/* 扩展的属性名, 用来取得数据， 以备可能的查询使用。 */
fieldName varchar2(64) null,
/* 扩展的属性的现实名称。用来向用户显示。 */
disName varchar2(64) null,
/* 属性值 */
value varchar2(1024) null,
created Date null,
modifiled Date null,
constraint PK_C_DIC primary key clustered (id)
);
其中要特别注意， key 属性用来存储的是一个 根据表名、主键值生成的一个字符串，这样可以简化在字典表中的记录，但不易于读取，所以我们用keys属性来存储可读的主键值， 采用json格式存储。
下面我们来看一个例子， 扩展用户(c_user)的地址和角色资源(c_role_res)的创建者，
这样就完成了属性扩展工作了。那么我们该怎样获取扩展的属性呢？ 很简单 ， 先计算 md5(table_name + k1 + k2), 的值 ，
比如用户表c_user就计算 md5(‘c_user’ + 1), 这样就的到一个值， 然后 通过
select fieldName, disName, value from C_Dic where
tableName='c_user' and key = '计算的md5值'
来获取给这条记录扩展的属性属性值。
至此。基本就完成了这个可扩展属性的设计工作。