blocks|key|325847|text|保持一致性远比你使用的特定方案重要得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325848|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Being consistent is far more important than what particular scheme you use.

blocks|key|3288079|text|我通常使用PascalCase，并且实体是单数的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288080|DoctorMain
DoctorProfile
DoctorPatient|code-block|syntax|javascript|3288081|它模仿了我的应用程序中类的命名约定，使所有内容都非常整洁、干净、一致、，并且每个人都很容易理解。|offset|length|style|BOLD|3288082|entityMap^0|0|0|W|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I typically use PascalCase and the entities are singular:

<pre><code>DoctorMain
DoctorProfile
DoctorPatient
</code></pre>

It mimics the naming conventions for classes in my application keeping everything pretty neat, clean, consistent, and easy to understand for everybody.

blocks|key|3074778|text|SQL不区分大小写的特性支持Underscores_Scheme。然而，现代软件支持任何类型的命名方案。然而，有时一些令人讨厌的bug、错误或人为因素会导致UPPERCASINGEVERYTHING，所以那些同时选择了Pascal_Case和Underscore_Case方案的人可以在很好的地方生活在他们所有的神经上。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3074779|entityMap^0|E|I|26|L|31|B|3D|F|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

Case insensitive nature of SQL supports <code>Underscores_Scheme</code>. Modern software however supports any kind of naming scheme. However sometimes some nasty bugs, errors or human factor can lead to <code>UPPERCASINGEVERYTHING</code> so that those, who selected both <code>Pascal_Case</code> and <code>Underscore_Case</code> scheme live with all their nerves in good place.

blocks|key|3288191|text|以上大多数内容的集合：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288192|3288193|不依赖于数据库中的大小写|unordered-list-item|3288194|不考虑名称的大小写或分隔符部分-只考虑单词|3288195|使用任何分隔符或大小写是您的语言|3288196|的标准|3288197|然后，您可以轻松地(甚至自动地)在环境之间转换名称。|3288198|但我要补充另一个考虑因素:当您从应用程序中的类移动到数据库中的表时，您可能会发现还有其他因素:数据库对象具有视图、触发器、存储的过程、索引、约束等-也需要名称。因此，例如，您可能发现自己只能通过通常只是一个简单的"select+*+from+foo“的视图访问表。可以将它们标识为仅带有'_v‘后缀的表名，也可以将它们放在不同的模式中。这种简单抽象层的目的是，在必要时可以对其进行扩展，以允许在一个环境中进行更改，以避免对另一个环境的影响。这并不会破坏上面的命名建议--只需要说明几件事。|3288199|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

An aggregation of most of the above: 

<ul>
<li>don't rely on case in the database</li>
<li>don't consider the case or separator part of the name - just the words</li>
<li>do use whatever separator or case is the standard for your language</li>
</ul>

Then you can easily translate (even automatically) names between environments. 

But I'd add another consideration: you may find that there are other factors when you move from a class in your app to a table in your database: the database object has views, triggers, stored procs, indexes, constraints, etc - that also need names. So for example, you may find yourself only accessing tables via views that are typically just a simple "select * from foo". These may be identified as the table name with just a suffix of '_v' or you could put them in a different schema. The purpose for such a simple abstraction layer is that it can be expanded when necessary to allow changes in one environment to avoid impacting the other. This wouldn't break the above naming suggestions - just a few more things to account for.

blocks|key|323872|text|因为这个问题不是特定于特定平台或DB引擎的，所以我必须说，为了最大限度地提高可移植性，您应该始终使用小写的表名。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323873|/a-z_*/实际上是唯一可以在不同平台之间无缝转换的名称模式。小写字母-数字%2B下划线将始终有效。|323874|正如在其他地方提到的，关系(表)名称应该是单数的：http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html|offset|length|323875|entityMap|0|LINK|mutability|MUTABLE|url|http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html^0|0|0|P|2K|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Since the question is not specific to a particular platform or DB engine, I must say for maximum portability, you should always use lowercase table names.

/[a-z_][a-z0-9_]*/ is really the only pattern of names that seamlessly translates between different platforms. Lowercase alpha-numeric+underscore will always work consistently.

As mentioned elsewhere, relation (table) names should be singular: <a href="http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html" rel="noreferrer">http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html</a>

blocks|key|323740|text|我使用下划线。几年前我做了一个Oracle项目，Oracle似乎强制我所有的对象名称都大写，这有点打击任何大小写方案。我不是一个真正的甲骨文爱好者，所以也许有一种我没有意识到的解决方法，但它让我使用了下划线，我再也没有回去过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323741|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I use underscores. I did an Oracle project some years ago, and it seemed that Oracle forced all my object names to upper case, which kind of blows any casing scheme. I am not really an Oracle guy, so maybe there was a way around this that I wasn't aware of, but it made me use underscores and I have never gone back.

blocks|key|3288140|text|我倾向于同意有人说这取决于你所使用的语言的约定(例如C#的PascalCase和snake_case的Ruby)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288141|不过，从来没有使用过camelCase。|3288142|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I tend to agree with the people who say it depends on the conventions of language you're using (e.g. PascalCase for C# and snake_case for Ruby).

Never camelCase, though.

blocks|key|3288280|text|在阅读了许多其他观点后，我认为使用语言的命名约定非常重要，只有当您是(并将成为)应用程序的唯一开发人员时，一致性才比命名约定更重要。如果你想要可读性(这是非常重要的)，你最好使用每种语言的命名约定。例如，在MySQL中，我不建议使用CamelCase，因为并非所有平台都区分大小写。所以这里下划线的效果更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288281|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

After reading a lot of other opinions I think it's very important to use the naming conventions of the language, consistency is more important than naming conventions only if you're (and will be) the only developer of the application. If you want readability (which is of huge importance) you better use the naming conventions for each language. In MySQL for example, I don't suggest using CamelCase since not all platforms are case sensitive. So here underscore goes better.

blocks|key|326067|text|这是我的五分钱。我的结论是，如果一个项目使用来自不同供应商的DB，那么有两种最好的方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|326068|326069|使用下划线。|ordered-list-item|326070|使用带引号的驼峰式大小写。|326071|326072|原因是某些数据库会将所有字符转换为大写，而将一些字符转换为小写。所以，如果你有myTable，当你使用DB时，它会变成MYTABLE或mytable。|offset|length|style|CODE|326073|entityMap^0|0|0|0|0|0|13|7|1N|7|1V|7|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@$K|W|L|X|M|N]|$K|Y|L|Z|M|N]|$K|10|L|11|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|P|$]]

These are my five cents. I came to conclusion that if DBs from different vendors are used for one project there are two best ways:

<ol>
<li>Use underscores. </li>
<li>Use camel case with quotes.</li>
</ol>

The reason is that some database will convert all characters to uppercase and some to lowercase. So, if you have <code>myTable</code> it will become <code>MYTABLE</code> or <code>mytable</code> when you will work with DB.

blocks|key|3075047|text|命名约定存在于一种语言的范围内，不同的语言有不同的命名约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3075048|默认情况下，SQL不区分大小写；因此，snake_case是一种广泛使用的约定。SQL还支持分隔标识符；因此，可以在选项中混合使用大小写，如camelCase+(Java，where+field+==+column)或PascalCase+(C#，where+tables+==+case+and+column+==+field)。如果你的数据库引擎不支持SQL标准，那就是问题所在。你可以决定接受它，也可以选择另一个引擎。(对于我们这些同时使用这两种语言编写代码的人来说，为什么C#必须有所不同是一个令人恼火的问题。)|3075049|如果您打算在服务和应用程序中只使用一种语言，请在所有层使用该语言的约定。否则，在使用该语言的领域中使用该语言最广泛使用的约定。|3075050|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Naming conventions exist within the scope of a language, and different languages have different naming conventions.

SQL is case-insensitive by default; so, snake_case is a widely used convention. SQL also supports delimited identifiers; so, mixed case in an option, like camelCase (Java, where fields == columns) or PascalCase (C#, where tables == classes and columns == fields). If your DB engine can't support the SQL standard, that's its problem. You can decide to live with that or choose another engine. (And why C# just had to be different is a point of aggravation for those of us who code in both.) 

If you intend to ever only use one language in your services and applications, use the conventions of that language at all layers. Else, use the most widely used conventions of the language in the domain where that language is used.

blocks|key|321320|text|不幸的是，这个问题没有“最好”的答案。正如@David所说，一致性远比命名约定重要得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|321321|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unfortunately there is no "best" answer to this question. As @David stated consistency is far more important than the naming convention.

blocks|key|321327|text|关于如何分隔单词有很大的差异，所以您必须选择您更喜欢的；但同时，似乎有一个几乎一致的表名应该是单数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|321328|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

there's wide variability on how to separate words, so there you'll have to pick whatever you like better; but at the same time, it seems there's near consensus that the table name should be singular.

blocks|key|321450|text|C#+approach|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|321451|Singular/Plural|321452|如果行中的记录只包含1个值，则为|321453|。|unordered-list-item|321454|如果是数组，则转到复数。当你获得这样的元素时，它也是非常有意义的。例如，您的数组列包含MostVisitedLocations:+London，NewYork，Bratislava|321455|321456|然后：|321457|foreach(var+mostVisitedLocation+in+MostVisitedLocations){
++++//go+through+each+array+element
}|code-block|syntax|javascript|321458|大小写|321459|对于我来说，用于表名的PascalCase和用于列的camelCase最有意义。但在我的.NET+5中，当我在camelCase中使用json对象名将json对象保存在dbs中时，System.Text.Json无法将其反序列化为object。因为您的模型必须是公共的，并且公共属性是PascalCase。因此，将表列(CamelCase)和json对象名(CamelCase)映射到这些属性可能会导致错误(因为映射区分大小写)。顺便说一句，使用NeftonsoftJson就不存在这个问题。|321460|所以我在app的结尾写道：|321461|表：+App.Admin，App.Pricing，UserData.Account|321462|价格列：+Id、、IsOnline。|321463|entityMap^0|0|B|0|0|F|0|0|0|0|0|0|0|0|3|0|0|0|0|2|0|8|A|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1E|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1F|8|@]|D|@]|E|$]]|$1|M|3|N|5|L|7|1G|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1I|8|@]|D|@]|E|$]]|$1|R|3|S|5|T|7|1J|8|@]|D|@]|E|$U|V]]|$1|W|3|X|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1N|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1O|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|14|3|15|5|6|7|1S|8|@$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|16|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]]|17|$]]

<h2>C# approach</h2>
Singular/Plural
<ul>
<li>singular if your record in row contains just 1 value.</li>
<li>If it is array then go for plural. It would make perfect sense also when you foreach such element. E.g. your array column contains MostVisitedLocations: London, NewYork, Bratislava</li>
</ul>
then:
<pre><code>foreach(var mostVisitedLocation in MostVisitedLocations){
 //go through each array element
}
</code></pre>
Casing
PascalCase for table names and camelCase for columns made the best sense to me. But in my case in .NET 5 when I had json objects saved in dbs with json object names in camelCase, System.Text.Json wasnt able to deserialise it to object. Because your model has to be public and public properties are PascalCase. So mapping table columns(camelCase) and json object names(camelCase) to these properties can result in error(because mapping is case sensitive).
Btw with NeftonsoftJson this problem is not present.
So I ended app with:
Tables: App.Admin, App.Pricing, UserData.Account
Columns: Id, Price, IsOnline.

blocks|key|3075157|text|2个基于用例的建议：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3075158|3075159|单数表名。|ordered-list-item|3075160|3075161|虽然我曾经相信表格名称的复数形式，但我在实践中发现，除了将表格视为集合之外，它几乎没有任何好处。|3075162|在对表名进行奇数运算时，您可以默默地将-table添加到您头脑中的单数表名中，然后一切都变得有意义了。|3075163|SELECT+username+FROM+UserTable+|code-block|syntax|javascript|3075164|听起来比|3075165|SELECT+username+FROM+UsersTable+|3075166|但是用来修复每一张桌子都是一种浪费。|3075167|单值化表名的实际论证：|3075168|person的复数是什么:person还是people？|3075169|这还是可以的。|3075170|但是你喜欢带有后缀-status的表格吗？状态？|3075171|太糟糕了，抱歉。通过将状态表单一化，但将其他表复数，很容易无意中犯下人为错误。|3075172|3075173|PascalCasing+%2B下划线约定。|3075174|3075175|给定表User、Role和多对多表User_Role。|offset|length|style|CODE|3075176|当所有表名默认都使用下划线时，考虑使用下划线大小写的user_role是可疑的。user_role是包含用户角色的表吗？在这种情况下，它不是，它是一个连接表。|3075177|在决定表格名称约定时，我认为放弃个人偏好并考虑现实生活问题的实际考虑是有用的，以便最大限度地减少可疑情况的发生。|3075178|正如许多答案和意见所表明的那样，无论你的个人观点是什么，不同的人会有不同的想法，尽管你是设置数据库的人，但你不会是唯一一个在数据库上工作的人(除非你这样做了，在这种情况下，你只是在帮助自己)。|3075179|因此，当你过去的决定受到质疑时，进行实际的论证是有用的(实际的意义是，它是否有助于我未来的同事避免可疑的情况)。|3075180|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|3|4|8|4|H|9|0|Q|9|14|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1R|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1T|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1U|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1V|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|1W|8|@]|9|@]|A|$]]|$1|R|3|S|5|M|7|1X|8|@]|9|@]|A|$N|O]]|$1|T|3|U|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|20|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|21|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|22|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|23|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|16|3|17|5|E|7|25|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|27|8|@$1B|28|1C|29|1D|1E]|$1B|2A|1C|2B|1D|1E]|$1B|2C|1C|2D|1D|1E]]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2E|8|@$1B|2F|1C|2G|1D|1E]|$1B|2H|1C|2I|1D|1E]]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]]|1O|$]]

2 suggestions based on use cases:
<ol>
<li>Singular table names.</li>
</ol>
Although I used to believe in pluralizing table names once, I found in practise that there is little to no benefit to it other than the human mind to think in terms of tables as collections. 
When singularising the table names, you can silently add -table to the singular table name in your head, and then it all makes sense again.
<pre><code>SELECT username FROM UserTable 
</code></pre>
Sounds more natural than
<pre><code>SELECT username FROM UsersTable 
</code></pre>
But post-fixing every table with is just a waste.
The actual practical argumentation for singularising table names:
What is the plural of person: persons or people? 
This is still ok. 
But how do you like a table with postfix -status? Statuses? 
That sucks, sorry.
It is easy to inadvertently make a human mistake by singularizing the status table, but pluralizing the other tables.
<ol start="2">
<li>PascalCasing + Underscore convention.</li>
</ol>
Given table <code>User</code>, <code>Role</code> and a many-to-many table <code>User_Role</code>. 
Considering underscore cased <code>user_role</code> is dubious when all table names are using underscore per default.
Is <code>user_role</code> a table that contains user roles? In this case it is not, it is a join table.
When deciding on table name conventions I think it is useful to let go of personal preference and take into account the real practical considerations of real life problems in order to minimize dubious situations to occur. 
As the many answers and opinions have indicated, whatever your personal opinion is, different people think differently, and you will not be the only person working on the database despite being the one who sets it up (unless you do, in which case you're only helping yourself). 
Therefore it is useful to have practical argumentation (practical in the sense of, does it help my future co-workers to avoid dubious situations) when your past decision is being questioned.

I've been reading a couple of questions/answers on StackOverflow trying to find the 'best', or should I say must accepted way, to name tables on a Database.

Most of the developers tend to name the tables depending on the language that requires the database (JAVA, .NET, PHP, etc). However I just feel this isn't right.

The way I've been naming tables till now is doing something like:

<pre><code>doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents 
</code></pre>

The things I'm concerned are:

<ul>
<li>Legibility</li>
<li>Quick identifying of the module the table is from (doctors||patients)</li>
<li>Easy to understand, to prevent confusions.</li>
</ul>

I would like to read any opinions regarding naming conventions.
Thank you.

Table Naming: Underscore vs Camelcase? namespaces? Singular vs Plural?

数据库

MySQL

Java

我在StackOverflow上读了几个问题/答案，试图找到“最好的”，或者我应该说是必须接受的方式，来命名数据库中的表。大多数开发人员倾向于根据需要数据库的语言(JAVA、.NET、PHP等)来命名这些表。然而，我只是觉得这是不对的。到目前为止，我对表的命名方式是这样的：doctorsMaindoctorsProfilesdoctorsPatientspatientsMainpatientsPr

问表格命名:下划线vs驼峰？名称空间？单数还是复数？
EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问表格命名:下划线vs驼峰？名称空间？单数还是复数？EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问表格命名:下划线vs驼峰？名称空间？单数还是复数？
EN