I found Naming Guidelines from MSDN, but is it any guideline for MSSQL database from Microsoft?
The naming conventions used in SQL Server's AdventureWorks database demonstrate many best practices in terms of style.
To summarize:
Object names are easily understood
Table names are not pluralized
("User" table not "Users")
Abbreviations are few, but allowed
(i.e. Qty, Amt, etc.)
PascalCase used exclusively with the
exception of certain column names
(i.e. rowguid)
No underscores
Certain keywords are allowed (i.e.
Name)
Stored procedures are prefaced with
"usp"
Functions are prefaced with "ufn"
You can find more details here:
AdventureWorks Data Dictionary
Stored Procedures in
AdventureWorks
Functions in AdventureWorks
One caveat: database naming conventions can be very controversial and most database developers I've met have a personal stake in their style. I've heard heated arguments over whether a table should be named "OrderHeader" or "OrderHeaders."
No, there isn't but the practices in the link you provided are good to keep in mind.
With respect to naming stored procedures - do not prefix them with "sp_" You can read more about why in this link:
"Do not prefix stored procedures with
sp_, because this prefix is reserved
for identifying system-stored
procedures."
I don't know what "best practices in terms of style" in the answer by #8kb (at the time of writing) means. Certainly some of the listed items ("Table names are not pluralized", "No underscores", etc) are mere style choices which are obviously subjective. I would have thought the personal preferences of the documentation team lead would be the greatest factor here.
As regards heuristics in SQL in general (as opposed to proprietary SQL such as T-SQL), there is but one book on the subject: Joe Celko's SQL programming style.Many of the choices for SQL Server's AdventureWorks database conflict with Celko's guidelines.
Celko's naming convention is based on on the international standard ISO 11179 e.g. specifies that a delimiting character (such as an underscore) should be used to separate elements in a name. Other style choices are similarly backup up by research e.g. using exclusively lower case letters for column names so aid scanning by the human eye. No doubt there are subjective personal preferences in there too but they are based on many years of experiences out in the field.
On the plus side, things have improved in the SQL Server docs in recent years e.g. SQL keywords capitalized, semi-colons to separate statements, etc. Adventure works is a vast improvement on Northwind and pubs. Now why can't the scripting feature in Management Studio spit out code that is a little easier on the eye?!
If you were to build a SQL Server naming conventions guide, I recommend starting with Konstantin's document on GitHub.
Related
As a contractor I'm exposed to several different code bases and I've noticed that while JAVA, .NET and PHP have code conventions with several degrees of adoption , SQL seems to vary a lot in the form it's written and generated not only from company to company but sometimes inside the same company.
Even languages such as HTML and CSS have widely referenced conventions, maybe not official , but well-know for being used major companies.
While I understand it might be difficult to create a industry accepted Ansi-SQL convention due to variance in SQL language implementantion , but I couldn't find a formal , community or company created convention even for specific RDBMS Sql flavors like TSQL or PL/pgSQL.
by code-convention I mean documents such
https://google.github.io/styleguide/jsguide.html
http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
https://www.php-fig.org/psr/
Each database engine works a little differently because the SQL naming conventions depend on the specific server.
There are also attempts to determine it "code convention for SQL", e.g.
https://www.sqlstyle.guide/
I'm familiar with the definitions of DDL, DML, and DCL as applied to SQL. There are lots of web sites and books that define and explain them. But no one seems to give an authoritative reference.
I'm interested in the origin of these terms. Did SQL invent them? Were they already used historically for other databases? Did some other standard create them, and they were used by SQL? Or did SQL even use them at all in the ISO specifications?
One book indicates that SQL92 included these terms, but I can't find them in the draft available online. (Maybe I'll have to purchase the final SQL92 ISO specification to know for sure.) SQL:1999 switched to a different classification system.
(One reason I'm curious is that, if these were general industry terms not invented by SQL, then it wouldn't necessarily be incorrect to continue using them, complementary to the new SQL classifications.)
Can anyone provide more insight on the origin of these terms, along with authoritative references to any standards or specifications that might have originally defined them?
According to Wikipedia's "Data definition language" entry:
The concept of the data definition language and its name was first
introduced in relation to the Codasyl database model, where the schema
of the database was written in a language syntax describing the
records, fields, and sets of the user data model.[1] Later it was used
to refer to a subset of Structured Query Language (SQL) for declaring
tables, columns, data types and constraints. SQL-92 introduced a
schema manipulation language and schema information tables to query
schemas. These information tables were specified as SQL/Schemata in
SQL:2003. The term DDL is also used in a generic sense to refer to any
formal language for describing data or information structures.
A bit more detail is provided in Wikipedia's "Codasyl" entry:
In October 1969 the DBTG published its first language specifications
for the network database model which became generally known as the
CODASYL Data Model. This specification in fact defined several
separate languages: a data definition language (DDL) to define the
schema of the database, another DDL to create one or more subschemas
defining application views of the database; and a data manipulation
language (DML) defining verbs for embedding in the COBOL programming
language to request and update data in the database. Although the work
was focused on COBOL, the idea of a host-language independent database
was starting to emerge, prompted by IBM's advocacy of PL/I as a COBOL
replacement.
And the "Data Base Task Group" Wikipedia entry says it published a final report 2 years later:
In April 1971, the DBTG published a report containing specifications
of a Data Manipulation Language (DML) and a Data Definition Language
(DDL) for standardization of network database model. The first DBTG
proposals had already been published in 1969. The specification was
subsequently modified and developed in various committees and
published by other reports in 1973 and 1978. The specification is
often referred to as the DBTG database model or the CODASYL database
model. As well as the data model, many basic concepts of database
terminology were introduced by this group, notably the concepts of
schema and subschema.
The above covers DDL and DML. Unfortunately Wikipedia's "Data control language" entry doesn't have much detail at the time of writing and I was unable to find the origins of this term elsewhere. But given the above and the Google Ngram graph shown below, would suspect it came later - possibly some time in the mid-1970s.
And here is another graph showing all three terms that appears to back this up:
Most SQL databases follow the ANSI SQL standards to a degree, but
The standard is ambiguous, leaving some areas open to interpretation (eg: how different operations with NULLs should be handled is ambiguous)
Some vendors contradict the standard outright or just lack functionality defined by the standard (eg: MySQL has a list of differences between the standard and their implementation)
Some databases will behave differently depending on how they are configured, but configuration can be changed to have them behave the same way (eg: Oracle performs case-sensitive string comparisons by default, while SQL Server does them case-insensitve)
There is some functionality that is not part of the standard but is implemented by different RDBMSs anyway, albeit with different names (eg: Oracle's LISTAGG = MySQL's GROUP_CONCAT)
Is there a resource with a comprehensive list of quirks and gotchas to pay attention to when you are trying to write something that is supposed to be compatible with multiple databases?
I'm not sure how comprehensive this list is, but maybe this will help -
http://troels.arvin.dk/db/rdbms/
Except of already mentioned some comparison you can find in Wikipedia
Also similar question was already posted on Stackoverflow where you can fin a couple of useful links.
Can anyone recommend a good ANSI SQL reference manual?
I don't necessary mean a tutorial but a proper reference document to lookup when you need either a basic or more in-depth explanation or example.
Currently I am using W3Schools SQL Tutorial and SQL Tutorial which are ok, but I don't find them "deep" enough.
Of course, each major RDBMS producer will have some sort of reference manuals targeting their own product, but they tend to be biased and sometime will use proprietary extensions.
EDITED: The aim of the question was to focus on the things database engines have in common i.e. the SQL roots. But understanding the differences can also be a positive thing - this is quite interesting.
Here's the ‘Second Informal Review Draft’ of SQL:1992, which seems to have been accurate enough for everything I've looked up. 1992 covers most of the stuff routinely used across DBMSs.
SQL isn't like C or Java, where there is a standard for the language, and then a number of companies and organizations are implementing the language as best they can, following the standard.
Instead, the major databases came before the SQL standard, and the standard is a sort of compromise where every database vendor wanted to get their particular dialect and features in the standard.
Therefore, there is much more variety between databases than between typical programming language compilers, and to use a database, you really need to know that particular SQL dialect.
Having said that, I've got Gultzan and Peltzer's SQL-99 Complete, Really here in my bookshelf. It is a good book if you need to know what the standard really contains. (And yes, there is a newer version since SQL-99, but noone seems to care.)
EDIT: Actually, there is not just one newer version since SQL-99, but three: SQL:2003, SQL:2006, and SQL:2008. And still noone seems to care. Actually, many don't even care about SQL-99, so SQL-92 is still, in a way, "the standard".
ANSI documents can all be purchased from -- you guessed it -- ANSI.
http://webstore.ansi.org/
The main problem with an ANSI SQL reference manual is that you can't find a DB which implements it. And when it does, then you'll find that ANSI SQL can't solve some of the daily problems. Which is why all professional databases define extensions.
So at work, you'll need a reference manual for the specific version of the database which you use.
This reminds me of my 2nd year university course where we learn relational theory instead of SQL.
Read a good book on Relational Theory. Database theory and practice have evolved since Edgar Codd originally defined the relational model back in 1969. Independent of any SQL products, SQL and Relational Theory draws on decades of research to present the most up-to-date treatment of the material available anywhere. Anyone with a modest to advanced background in SQL will benefit from the many insights in this book.
Oreilly January 2009
I found the best way to learn SQL was to actually get to writing queries and understanding the nature of joins/conditionals etc. I found this link with a lot of DIY examples to be the best : http://sqlzoo.net/
It's a littel outdated, but this book is really helpful is looking at how the differnt vendors implement things, I belive it includes ANSII standard.
http://www.amazon.com/SQL-Nutshell-2nd-Kevin-Kline/dp/0596004818/ref=sr_1_1?ie=UTF8&s=books&qid=1257963172&sr=8-1
I really like just about anything Joe Celko has written Celko's Books
I think this may be helpful to you.
Understanding the ANSI SQL standard
By: Kevin Kline
http://www.amazon.com/gp/product/1565927443/102-0105946-4028970?v=glance&n=283155
The DevGuru resources always worked well for me:
http://www.devguru.com/technologies/t-sql/home.asp
Although I must admit it's not strictly an 'ANSI' focused resource. I've always been MS SQL centric, and it was helpful to me when I was starting out. IMHO Your best bet will be to use several resources - specifically including at least one of for each DB platform you want to use.
To Quote the DevGuru intro for their T-SQL resource:
Although there are standards for SQL,
such as ANSI SQL92 and SQL99, most
databases use their own dialect and/or
extentions. Microsoft's flavor of SQL
used in SQL Server 7 and SQL Server
2000 is called T-SQL. While many of
the examples in this quick reference
may work on other databases, it is
assumed that SQL Server 2000 is used,
especially for advanced topics such as
stored procedures.
I work at a company that has some very non-standardized SQL conventions (They were written by Delphi Developers years ago). Where is the best place that I can find SQL industry standard convention definitions that are most commonly used?
In his book "SQL Programming Style," Joe Celko suggests a number of conventions, for example that a collection (e.g. a table) should be named in the plural, while a scalar data element (e.g. a column) should be named in the singular.
He cites ISO-11179-4 as a standard for metadata naming, which supports this guideline.
there aren't any
it there were, they'd be obsolete
if they're not obsolete, you won't like them
if you like them, they're insufficient
if they're sufficient, no one else will like them
seriously, strive for readability, i.e. use meaningful field and table names; nothing else is really necessary
(ok some common prefixes like usp and udf and udt may be useful, but not required)
This is the best one I've ever seen... Naming Conventions
However, standards should really be all about clarity, simplicity, and ease of adoption among your team.
There shouldn't be a bunch of incredibly strict naming guidelines, it should focus on style.
The point is not to torment developers, it is to create a congruent style throughout the system so that it is easy to move from one section to another.
There are no exact industry-wide SQL standards. The best option is to google for SQL standards because several knowlegable people have posted some rather good, extensive, and complete documents on the subject. Read through them and absorb the items that apply to your environment.
Here you can find a lot of Rules to better SQL /SQL Server.
Yes, it's the company that I am working for, but they are good!
And these rules come from experience with client projects.
Have a look and take what you like!