As @jensolzhu mentioned in #858, should shardingColumn be Case Sensitive or Case Insensitive?
As @wujun8 mentioned in #1141, should tableAlias be Case Sensitive or Case Insensitive?
Please vote for you preference and tell why.
个人建议不区分大小写。在实际应用中,对于大小写不区分的数据库会带来一些麻烦,需要严格要求dba、开发人员注意大小写。
default with mysql's configuration, and support custom settings.
load case Insensitive config from database, and then do Case Sensitive or Case Insensitive is better
Case Insensitive.
通过配置是否区分大小写比较合理;
目前项目里只能通过针对不需要分库分表Table配置actual-data-nodes解决,但是表多的时候很麻烦;或者修改mysql大小写敏感配置;
@terrymanu commented on 2018年5月24日 GMT+8 下午2:04:
load case Insensitive config from database, and then do Case Sensitive or Case Insensitive is better
Agreed with @terrymanu
I prefer Case Insensitive. Here are some reaseons:
For MySQL, Column, index, stored routine, event, and resource group names are not case-sensitive on any platform, nor are column aliases.
Please note that the lower_case_table_names MySQL system variable is used to control how table and database names are stored on disk and used in MySQL. This system variable can not influence column or aliases, and none system variable can. Please refer to https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html for more details.
For PostgreSQL, Case Insensitive without double quotes.
For Oracle, Case Insensitive without double quotes.
For SQLServer, Case Insensitive by default. Configurable.
Sharding-Sphere do not need to intercept SQLs, let the SQLs go and the Databases will judge and response. Otherwise, Sharding-Sphere have to manage the configuration only for SQLServer in metada, and will meet shutdown when the configurations are inconsistent.
algorithmExpression will be transform to groovy script which is case sensitive. So columnName should not cast to lower case.
Revert shardingColumn to case sensitive: https://github.com/sharding-sphere/sharding-sphere/pull/1706
Most helpful comment
load case Insensitive config from database, and then do Case Sensitive or Case Insensitive is better