Throughout this schema I’ve used Camel Casing, with most single word column and single word table names. Here’s an example I put together with some naming conventions I’ve found useful, reduces confusion, and manages to tell a reasonable amount of information about the domain space and schema of the database without conflicts. This could be split out to three schemas Table Names for Core Tables, for multiple schemas, within the E-commerce Domain: Table Names for Pricing in an E-commerce Domain: Table Names for Returns in an E-commerce Domain: Naming these objects accordingly is easiest by following the same convention as the table naming convention.įor example, if the table naming convention is following Camel Case then continue that In many databases there are additional organizational and related structures that help us to setup tables, functions, stored procedures, compiled SQL/queries, and other objects in groupings.
UNIVERSAL DATABASE NAMING CONVENTIONS CODE
For example, when table names are singular, many ORM frameworks when generating code would take a singular table name like Customer and make it Customers and have objects of Customer. However, be sure to choose one or the other so that frameworks, Object Relationship/Relational Mappers/Mapping (ORM), and other tools can effectively name things when used.
It’s also a good idea to choose plural or singular for table names. For other metadata, indexes, and related names use a respective preface or postfix conventions. Columns that are primary or foreign keys should be prefaced with PK_ and FK_ respectively, and in my moderately humble opinion, stick to just PK or FK using Camel or Pascal Case. Ideally names would be single words like “User”, “Transactions”, “railroad”, or “system” and exclude compound names like “railroadSystem” until it is needed to prevent confusion or naming collisions. Use singular word names if at all possible, only moving to compound word naming if absolutely necessary. Such as “BankingUsers”, “Transactions”, “railroads”, or “railroad_Systems”. Use meaningful names from the business or organizational domain being modeled. In summary, use a case scheme like Camel or Pascal Case but do not use Snake or Kebab Case. Table, column, and related object names should contain only letters, numbers as characters in the body of the name and not as the preface characters, underscores and absolutely no spaces or special characters. I’m often working with a variety of databases so this post will cover naming convention ideas and respective patterns and practices around them that would work with every conceivable database I know to exist! Table, Column, Tuple, or Related Naming Conventions If an identifier is double quoted, you can also yse keywords, albeit I would very strongly reccommend against this practice.Īs these examples provide, there are a number of ways that the rules are just different enough from one database to another that it is often very helpful to use a naming convention that would work across databases. After the first letter and identifier can have letters, underscores, digits, or dollar signs. SQL identifiers in Postgres and key words must begin with letters (a-z), which include diacritical marks and non-Latin letters. These would all be the same without double qutoes, add the double quotes around those names and “MYTABLE” becomes different than “MyTable” and different than “mytable”. Throw in some double quotes however and you can use names like MyTable, MYTABLE, and mytable. Postgres names fold to lowercase versus uppercase, which is different then many other databases. 
But let’s talk about some other database specific rules for other databases. There are many other rules about naming things in SQL Server.
Then in scripts these names have to be single quoted. To force SQL Server to use non-standard table names one can use brackets. Table names must be less than 128 characters. What We’re Working With, Some of The Database Rules It’s always good to have some good conventions to work with, and the descriptions and ideas in this post are a solid starting point. This also applies to schema-less databases, distributed systems databases, graph, time series, or whatever else I am working with. In this post I’ve put together some of the naming conventions, rules, and ideas that I tend to follow when creating database schemas to work with.
0 kommentar(er)
