DevCampus Database Naming Conventions

Database Naming Conventions Version 1.1
Last Revised May 13, 2004 by Jason Mauss

The main goal of adopting a naming convention for database objects is so that you and others can easily identify the type and purpose of all objects contained in the database. The information presented here serves as a guide for you to follow when naming your database objects. When reading these rules and guidelines remember that consistent naming can be the most important rule to follow. Keep in mind that  following the guidelines as outlined in this document can still produce long and cryptic names, ultimately, your unique situation will dictate the reasonability of your naming convention. The goal of this particular naming convention is to produce practical, legible, concise, unambiguous and consistent names for your database objects.

While most databases contain more types of objects than those discussed here (User Defined Types, Functions, Queries, etc.), the 7 types of objects mentioned here are common among all major database systems. Think of this as a generic DBMS-neutral guide for naming your objects.

The following types of database objects are discussed here:

  1. Tables
  2. Columns (incl. Primary, Foreign and Composite Keys)
  3. Indexes
  4. Constraints
  6. Stored Procedures
  7. Triggers


  • Limit the name to 30 characters (shorter is better)
  • Use only letters or underscores (try to avoid numbers)
  • Try to use underscore characters as little as possible. PascalCase notation achieves the same word separation without them.
  • Use a letter as the first character of the name. (don't start names with underscores)
  • Avoid abbreviations (can lead to misinterpretation of names)
  • Avoid acronyms (some acronyms have more than one meaning eg. "ASP")
  • Makes the name readable (they shouldn't sound funny when read aloud)
  • Avoid using spaces in names even if the system allows it.

When naming your database tables, give consideration to other steps in the development process. Keep in mind you will most likely have to utilize the names you give your tables several times as part of other objects, for example, procedures, triggers or views may all contain references to the table name. You want to keep the name as simple and short as possible. Some systems enforce character limits on object names also. For example, in Oracle you are limited to about 30 characters per object.

Rule 1a (Plural Names) - Table names should be plural, for example, "Customers" instead of "Customer". This rule is applicable because tables are logical collections of one or more entities as records - just like collection classes are logical collections of one or more objects. If you were to first draw an abstract data model like a NIAM/ORM model, you might have singular entity names like "Customer" or "User" but, they should be changed to the plural form when building the actual tables. For table names with multiple words, only the last word should be plural, for example, "UserRoles" and "UserRoleSettings".

Rule 1b (Prefixes) - Used correctly, table prefixes can help you organize your tables into related groups or distinguish them from other unrelated tables. Used poorly, they can cause you to have to type a lot of unnecessary characters. We'll discuss what not to do first. Do not give your table names prefixes like "tbl" or "TBL_" as these are just redundant and unnecessary. It will be obvious which names are the table names in SQL statements because they will always be proceeded by the FROM clause of the SELECT statement. Not all prefixes are bad. In some cases, your tables might be sharing a schema/database with other tables that are not related in any way. In this case, it is sometimes a good idea to prefix your table names with some characters that group your tables together. For example, for a healthcare application you might give your tables an "Hc" prefix so that all of the tables for that application would appear in alphabetized lists together. Note that even for the prefix, use Pascal Case. This is discussed in Rule 1c. Do not use underscores in your prefixes, which is discussed in more depth in Rule 1d. The last kind of prefix that is acceptable is one that allows you to group logical units of tables. A plausible example could entail a large application (30 to 40+ tables) that handled both Payroll and Benefits data. You could prefix the tables dealing with payroll with a "Pay" or "Prl" prefix and give the tables dealing with benefits data a "Ben" or "Bfts" prefix. The goal of both this prefix and the aforementioned shared schema/database prefix is to allow you to group specific tables together alphabetically in lists and distinguish them from unrelated tables. Lastly, the shared schema/database prefix is a higher grouping level and comes first in the name, for example, "HcPayClients" not "PayHcClients".

Rule 1c (Notation) - For all parts of the table name, including prefixes, use Pascal Case. Using this notation will distinguish your table names from SQL keywords (all capital letters). For example, "SELECT CustomerId_Pk, CustomerName FROM MyAppGroupTable WHERE CustomerName = '%S'" shows the notation for the table name distinguishing it from the SQL keywords used in the query. PascalCase also reduces the need for underscores to visually separate words in names.

Rule 1d (Special Characters) - For table names, underscores should not be used. The underscore character has a place in other object names but, not for tables. Using Pascal Case for your table name allows for the upper-case letter to denote the first letter of a new word or name. Thus there is no need to do so with an underscore character. Do not use numbers in your table names either. This usually points to a poorly designed data model or irregularly partitioned tables. Do not use spaces in your table names either. While most database systems can handle names that include spaces, some systems require you to add more characters around the name when referencing it (like [table name] for example) which goes against the rule of keeping things as short and simple as possible. If you are developing in a non-english language, do not use any of that language's special characters.

Rule 1e (Abbreviations) - Avoid using abbreviations if possible. Use "Accounts" instead of "Accts" and "Hours" instead of "Hrs". Not everyone will always agree with you on what your abbrevations stand for - and - this makes it simple to read and understand for both developers and non-developers. This rule can be relaxed for junction table names (See Rule 1f). Do not use acronyms.

Rule 1f (Junction a.k.a Intersection Tables) - Junction tables, which handle many to many relationships, should be named by concatenating the names of the tables that have a one to many relationship with the junction table. For example, you might have "Doctors" and "Patients" tables. Since doctors can have many patients and patients can have many doctors (specialists) you need a table to hold the data for those relationships in a junction table. This table should be named DoctorsPatients". Since this convention can result in lengthy table names, abbreviations sometimes may be used at your discretion.

When naming your columns, keep in mind that they are members of the table, so they do not need the any mention of the table name in the name. The primary key field is typically the only exception to this rule where including the table name is justified so that you can have a more descriptive field name than just "Id". "CustomerId" is acceptable but not required. Just like with naming tables, avoid using abbreviations, acronyms or special characters. All column names should use Pascal Case to distinguish them from SQL keywords (all upper case).

Rule 2a (Identity Primary Key Fields) - For fields that are the primary key for a table and uniquely identify each record in the table, the name should simply be “Id“ since, that's what it is - an identification field. This name also maps more closely to a property name like “Id“ in your class libraries. Another benefit of this name is that for joins you will see something like
      "Customers JOIN Orders ON Customer.Id = Orders.CustomerId“
which allows you to avoid the word “Customer“ again after the Customer table.

Rule 2b (Foreign Key Fields) - Foreign key fields should have the exact same name as they do in the parent table where the field is the primary key - with one exception - the table name should be specified. For example, in the Customers table the primary key field might be "Id". In an Orders table where the customer id is kept, it would be "CustomerId". There is one exception to this rule, which is when you have more than one foreign key field per table referencing the same primary key field in another table. In this situation, it might be helpful to add a descriptor before the field name. An example of this is if you had an Address table. You might have another table with foreign key fields like HomeAddressId, WorkAddressId, MailingAddressId, or ShippingAddressId. 

Rule 2c (Composite Keys) - If you have tables with composite keys (more than one field makes up the unique value) then instead of just “Id“ you should use a descriptor before the “Id“ characters. Two fields like “ModuleId“ and “CodeId“ might make up the composite key, for example. If you don't see an “Id“ column in the table - you'll know that a composite key is used to uniquely identify records.

Rule 2d (Prefixes) - Do not prefix your fields with "fld_" or "Col_" as it should be obvious in SQL statements which items are columns (before or after the FROM clause). Including a two or three character data type prefix for the field is optional and not recommended, for example, "IntCustomerId" for a numeric type or "VcName" for a varchar type. However, these data type abbreviations are DBMS specific and are outside the scope of this document.

Rule 2e (Data Type Specific Naming) - Boolean fields should be given names like "IsDeleted", "HasPermission", or "IsValid" so that the meaning of the data in the field is not ambiguous. If the field holds date and/or time information, the word "Date" or "Time" should appear somewhere in the field name. It is sometimes appropriate to add the unit of time to the field name also, especially if the field holds data like whole numbers ("3" or "20"). Those fields should be named like "RuntimeHours" or "ScheduledMinutes".

Since indexes are always related to a table or view, it makes the most sense to use the name of the table or view, as well as the column(s) they index, in the index name, along with some characters that specify the type of index it is. This naming convention also allows you, if looking at a list of indexes, to see the indexes ordered by table, then column, then index type.

Rule 3a (Naming Convention) - The naming convention for indexes follows this structure:


where "U/N" is for unique or non-unique and "C/N" is for clustered or non-clustered. This naming convention is unique among database objects, so adding characters to denote it being an index, like "idx" is not necessary. The naming convention alone is self-documenting and indentifies it as an index. For indexes that span multiple columns, concatenate the column names. "ProductsIdUC" indicates a unique, clustered index on the Id column of the Products table. OrderDetailsOrderIdCustomerIdNN" indicates a non-unique, non-clustered index on the OrderId and CustomerId columns in the OrderDetails table. Since this name is rather lengthy with both "OrderId" and "CustomerId" spelled out, they could be shortened to OrdId and CustId. However, notice that by using Pascal Case, thus not needing to use underscores, it is possible to keep the name of a complex index to about 30 characters.
Rule 3b (Prefixes and Suffixes) - Avoid putting a prefix like "idx" or "IDX_" before your indexes. This is not necessary due to the naming convention discussed in Rule 3a. A suffix of "_idx" or "IDX" is not necessary either for the same reason.

Constraints are at the field/column level so the name of the field the constraint is on should be used in the name. The type of constraint (Check, Referential Integrity a.k.a Foreign Key, Primary Key, or Unique) should be noted also. Constraints are also unique to a particular table and field combination, so you should include the table name also to ensure unique constaint names across your set of database tables.

Rule 4a (Naming Convention) - The naming convention syntax for constraints looks like this:

     {constraint type}{table name}_{field name}

1. PkProducts_Id  - primary key constraint on the Id field of the Products table
FkOrders_ProductId    - foreign key constraint on the ProductId field in the Orders table
3. CkCustomers_AccountRepId - check constraint on the AccountRepId field in the Customers table

The reason underscores are used here with Pascal Case notation is so that the table name and field name are clearly separated. Without the underscore, it would become easy to get confused about where the table name stops and the field name starts.

Rule 4b(Prefixes) A two letter prefix gets applied to the constraint name depending on the type
     Primary Key: Pk
     Foreign Key: Fk
     Check: Ck
     Unique: Un

Views follow many of the same rules that apply to naming tables. There are only two differences (Rules 5a and 5b). If your view combines entities with a join condition or where clause, be sure to combine the names of the entities that are joined in the name of your view. This is discussed in more depth in Rule 5b.

Rule 5a (Prefixes) - While it is pointless to prefix tables, it can be helpful for views. Prefixing your views with "Vw" or "View" is a helpful reminder that you're dealing with a view, and not a table. Whatever type of prefix you choose to apply, use at least 2 letters and not just "V" because a prefix should use more more than one letter or its meaning can be ambiguous.

Rule 5b (View Types) - Some views are simply tabular representations of one or more tables with a filter applied or because of security procedures (users given permissions on views instead of the underlying table(s) in some cases). Some views are used to generate report data with more specific values in the WHERE clause. Naming your views should be different depending on the type or purpose of the view. For simple views that just join one or more tables with no selection criteria, combine the names of the tables joined. For example, joining the "Customers" and "StatesAndProvinces" table to create a view of Customers and their respective geographical data should be given a name like "VwCustomersStatesAndProvinces". For a view that is more like a report, a name like "VwDivisionSalesFor2004" might make more sense.

Unlike a lot of the other database objects discussed here, stored procedures are not logically tied to any table or column. Typically though, stored procedures perform one of the CRUD (Create, Read, Update, and Delete) operations on a table, or another action of some kind. Since stored procedures always perform some type of operation, it makes sense to use a name that describes the operation they perform. Use a verb to describe the type of operation, followed by the table(s) the operations occur on.

Rule 6a (Prefixes or Suffixes) - The way you name your stored procedures depends on how you want to group them within a listing. If you'd like to group them by the type of CRUD operation they perform, then prefix the name with "Create", "Get", "Update" or "Delete". Using this kind of prefix will, for example, group all of your "Create" procedures together since they will all start with the Create prefix, like "CreateProductInfo" or "CreateOrder". If instead, you would like to have your procedures ordered by the table they perform a CRUD operation on, adding "Create, Get, Update, or Delete" as a suffix will do that for you. For example, "ProductInfoCreate" or "OrdersCreate". If your procedure returns a scalar value, or performs an operation like validation, you should not use a CRUD prefix or suffix. Instead use the verb and noun combination. For example, "ValidateLogin"

Rule 6b (Grouping Prefixes) - If you have many stored procedures, you might want to consider using a grouping prefix that can be used to identify which parts of an application the stored procedure is used by. For example, a "Prl" prefix for Payroll related procedures or a "Hr" prefix for Human Resources related procedures can be helpful. This prefix would come before a CRUD prefix (See Rul 6a).

Rule 6c (Bad Prefixes) - Do not prefix your stored procedures with something that will cause the system to think it is a system procedure. For example, in SQL Server, if you start a procedure with "sp_", "xp_" or "dt_" it will cause SQL Server to check the master database for this procedure first, causing a performance hit. Spend a little time researching if any of the prefixes you are thinking of using are known by the system and avoid using them if they are.

Triggers have many things in common with stored procedures. However, triggers are different than stored procedures in two important ways. First, triggers don't exist on their own. They are dependant upon a table. So it is wise to include the name of this table in the trigger name. Second, triggers can only execute when either an Insert, Update, or Delete happens on one or more of the records in the table. So it also makes sense to include the type of action that will cause the trigger to execute.

Rule 7a (Prefixes and Suffixes) - To distinguish triggers from other database objects, it is helpful to add "Trg" as a prefix or suffix. For example any of these combinations work: Trg_ProductsIns, ProductsInsTrg, Products_InsTrg, or InsProducts_Trg. As long as you include the table name, the operation that executes the trigger (Ins, Upd, or Del) and the "Trg" letters, it should be obvious to someone working with the database what kind of object it is. As with all conventions you use, pick one and remain consistent.

Rule 7b (Multiple Operations) - If a trigger handles more than one operation (both INSERT and UPDATE for example) then include both operation abbreviations in your name. For example, "Products_InsUpdTrg" or "TrgProducts_UpdDel"

Rule 7c (Multiple Triggers) - Some systems allow multiple triggers per operation per table. In this case, you should make sure the names of these triggers are easy to distinguish between. For example "Users_ValidateEmailAddress_InsTrg" and "Users_MakeActionEntries_InsTrg".


  • Jason,

    Good article, but I'll have to disagree with you on the _Pk, _Fk business. It's not only superflous, but it will cause a major headache when keys change. And they sure do. Consider going from a straight text field (let's say "Status") to a constrained lookup table, now you're stuck with changing the column name (to "Status_fk") or having an inconsitant naming convention. Ditto for the column datatype prefix, as those can change too (eg, intQuantity becomes a float because they need partial returns, or something).

    And kudos for saying "No" to the "tbl" prefix! It's very frusterating to have view's named tblWhatever and tables named vwSomething.

    -- Alex

  • Jason,

    Overall, great job. I just got done reviewing a database, and having something like this ahead of time would have been awesome.

    I do agree with Alex above though. I don't like the _Pk and _Fk in the columns, because they can change. I would also say there are exceptions to the Foreign key always being named the same as the field in the lookup table. For example, if I have a table of addresses, my profile may have a mailing, shipping and billing address associated with them. In some cases it might make sense to have a many to many table between them, but in some cases it makes sense to just have three columns for MailingAddressId, ShippingAddressId and BillingAddressId, where the PK in the Addresses table might be AddressId. I would agree it should CONTAIN the name of the original field, but would add that it could have a descriptor in front of it.

    I'll be using this as a reference whenever I do database design work from now on though! Great job!


  • Thanks for the feedback Joel - that's actually a really good point you make about multiple foreign keys mapping to the same primary key. I think I'll make another rule stating that it's OK to add a descriptor in front of the Foreign key field name - I actually think I've also done that before myself so, it must've slipped my mind.

    Can someone give me an example of primary or foreign key fields needing to change though? That doesn't happen very often, if ever on the databases I've designed or worked with. Maybe I just can't envision the situation that would cause that.

  • Primary keys, maybe not. Foreign keys changing is unlikely, but I can see them being added - the example of a status being hard coded into the application (right or wrong) and later being added to a lookup table. I would rather just call the field status, and leave it alone.

    I guess if you do your due diligence up front, you would be OK. The keys shouldn't change, and you should build all of your lookups into the database.

    My biggest thing is that I just don't like typing underscores! Plus, (at least for primary keys) if the key is the singular table name with Id added, I don't see a need for the _Pk, and if it's another type of Id, then it's a foreign key. If it's a composite key, most likely it's a junction table, so you know you are dealing with composite keys. Maybe it's just me. Plus, it looks better without the underscores if you use typed datasets!

    Just my two cents (again).


  • Ommitting the name prefixes makes sense when using SQL but what about when you are using PL/SQL, VBA, perl and all the other irregularities in the world?

    Thnx for addressing the topic!!

  • Gareth,

    Are you talking about writing stored procs and data access code? For stored procs (PL/SQL or TSQL) it should be obvious what the entity is you're working with (field or table or other) by where it appears in the SQL statement. If you're writing VBA or Perl you really shouldn't be embedding SQL within your code anyway, it's not a good idea. I typically use an external XML file to store all my queries, which I populate doing just copy and paste from a tool like Query Analyzer or TOAD. Then, outside of data access code, you should just be accessing properties of objects and not fields directly from DataSets or Recordsets.

  • Good work, here are some comments:

    I must disagree with inconsistent use of underscore. If you are trying to create rules your overall conventions (for all database objects) could not be: "Try to use ... as little as possible", the rule must be: "Do not use...". Later you could make exception to the rule but with the good reason. Using underscores in naming constraints is a bad decision.

    When naming database column I'm traying to follow object paradigm, table is representing an object and columns are properties of that object. For example if you have an object name File then the file name is usually represented by the property Name: File.Name. It is not named FileName or File_Name or something like that. So I strongly agree with not using table names in column names. I follow the same logic for id-s, for the column which is unique identifier of the object I use the name ID (not the FileID). When that column is the foreign key in another table then I name it FileID (would be great to name it File.ID to stick with the object paradigm, but most DBMS will have extra requirements for that).

    Naming ID columns is realy important because we are using them joins so it is important that thay look intuitive.

    I'm using:

    ... File inner join Directory on File.ID = Directory.FileID ...

    it looks to me little better than:

    ... File inner join Directory on File.FileID = Directory.FileID ...

    but this has a lot of repeating information's:

    ... File inner join Directory on File.FileId_Pk = Directory.FileId_Fk ...


  • My general experience is that *any* standard is better than none (or four different, incompatible ones applied to the same database, as I struggle with at the moment*) and a good standard is (obviously) better yet.

    I actually found little to quibble at, other than not liking having "Ck" as suffix in column names and prefix in constraints when it expands to different meanings. I know the context is different, but my poor old brain doesn't always remember to context-switch like it used to... ;-)

    Would it not be more transparent to use "Ch" (or similar) for check constraints?


    * but it's OK, we're fixing that: a new, "definitive" standard has been proposed (let's get back to the "tbl" prefix, yay!) and we're going to apply that to all new work. We're going to leave the existing mess as it is. My cup runneth over.

  • I have to say that standard hurts my eyes. We do things in a completely different manner, but I agree with Mike, any standard is better than one.

  • Jeff - what about it hurts your eyes? What kind of standard do you employ? I'm very open to feedback on ways to improve the conventions for this.

  • sdfasdfasdfjleiaodsjfjlsaf

  • I just wanted to say thanks for the great article! My office doesn't have any standards, and this is the best convention I have found. Hopefully we'll be adapting it.

  • I tend to agree with Jason on the table names, but disagree with him on the concatination of table and field name. Instead of having to use table aliases one can just use the whole table name so in Jasons example of:

    SELECT p.project_name, a.activity_name

    FROM project p LEFT JOIN activity a ON p.project_id = a.project_id

    WHERE p.project_name = "world domination"

    -- the correct second way would be: --


    FROM project p LEFT JOIN activity ON =

    WHERE = "world domination"

    This is still SHORTER then the virst version where you have to "add" p. or a.

    However I have prefixed the table name to a field in the example of "Value" (value being a reserved word, otherwise requiring it to be [Value])

  • Sorry for the confusion, I meant Justin not Jason in my post above

  • Thanks for the comments both David and Justin - I'll look them over and see what I can take from them and add to the standard perhaps to be v1.2.

    Your feedback is appreciated guys.

  • Just a couple of comments from my own experiences:

    Often in the life of a database, I need to split a table into several tables. Reasons could be normalising an un-normalised table, adding multilingual capability or simply adding a one-to-one table with an attribute that only some of the rows can have.

    This means I would rename the tables appropriately, but create a view with the original table name so that any existing applications will still work until I get around to implementing the new functionality.

    The relational model is big on the separation of logical and physical data. An intention is that the underlying physical representation of the data can change without breaking applications. Any naming convention that has the inclusion of physical information about an object will therefore contravene the spirit of the model. It - the convention - will also be broken in the not unusual cases I mention above.

    This also applies to adding descriptive information to column names. It would be better to use a short version of the domain name if possible, but I haven't worked that part through yet.

    Having said all that, people in glass houses shouldn't throw stones. My own conventions are in a state of chaos - that's why I am reading yours:-)

  • I would say it's almost a neccessity to prefix views in some way. From my own experience I was debugging someone else's code and it turned out the developer was trying to update a view which had been named without a prefix and looked like a genuine table name!

    Now, just to be awkward, I have read in some security articles concerning web based applications that, as an added precaution, in case the database is compromised, tables containing sensitive data should not be named with what they represent e.g. customer account information should not be named CustomerAccount but given some boring name (PaintDrying perhaps?). This will make the SQL less readable, and, of course, you can't rely on security through obscurity, but it's something to consider.

    However, I will be adopting the majority of these conventions for my company in the near future. Thanks.

  • lol, thats hilarious. Can't believe we didn't think of that sooner. I guess I'll have to change all my tables named "BigMoneyIfYouCrackIt" to something less obvious, who woulda thunk it. How about "PersonalMedicalFilesINSIDE!". Brilliant.

  • Sorry I got another one... what do you think the top-level most secretive government information table is called in their database? Probly some randomly generated sequence of letters and numbers or something... but imagine what it was back before people thought about it... "TopSecret" perhaps? Or wait, maybe they followed this convention, "TopSecrets", yup, that sounds better =p

  • Regarding table names being plural or singular:
    IMHO it depends on what each row in the table represents. In the majority of applications, each row models a singular object or type of object.

  • Not to beat a dead horse (because PETA would have a fit), but concerning the plurality of table names. Here's my "thinking out loud". Is it so bad to have table names "naturally plural" and the pk columns singular? For example, the Activities table has a primary key field of ActivityId. The table does contain a group of activities, and the individual row contains one activity and is therefore named ActivityId.

    What I mean about "naturally plural" is if you have a table "Fish" it contains a collection of multiple fish. The primary key column would also be named fish, which is the singular form of the word because one row is one (singular) fish.

    Like I said, just thinking out loud.


  • Avoid Generic Field Names
    Do not use generic field names like status. There can be many different kinds of status: account, customer, order, payment, product, etc. This makes it easy, for example, to find all references to orderStatus. It may make the names longer, but is well worth it in a large DB.

    Many tables need a dateAdded field. Use the same name in all tables or you’ll go nuts having to look up what it is called. For example auditlog.dateadded and orders.dateadded instead of auditlog.logdate and orders.orderdate.

    Primary Keys and Foreign Keys
    Many people advocate calling the PK field ID and FK fields tablenameID. One good thing about this is that it lets you easily find FK references. The bad thing about it is that it becomes very difficult to find all primary key references for a given table, since they are all named ID.
    Using tablenameID for both FK and PK gets rid of the name collision of the ID field but means that you can’t easily find FK references separate from PK references.
    An alternative is to name PK as tablenamePK and FK as tablenameFK. This is the easiest way to quickly find whatever it is that you are looking for. The only problem is that some people have been using ID for so long that they have a hard time adjusting to PK/FK. However, as long as it is done consistently then coding is very easy, e.g. where table1.table1pk=table2.table1fk.

  • This article is a great source for developers. I in the initial stage of designing an HR + Payroll application database, and I will apply most of the rules specified in this article.

    By the way I just shifted from Delphi (Pascal based) environement to Visual Studio, and I am quite comfortable with Pascal type naming convensions.

    Great Job.

  • @ Tariq:

    An HR/Payroll app? Really? that hasn't been done to death?

    ff_mac said "Using tablenameID for both FK and PK gets rid of the name collision of the ID field but means that you can’t easily find FK references separate from PK references."

    Huh? you have no constraint table to query that defines PKs and FKs. No it's not hard to tell the difference in any real RDBMS. What is hard is to find missing constraints left by sloppy developers when the column changes name from table to table.

    Plural table names: I can always tell the people who never script changes to their databases. If you have a COMPANIES table is the ID column Companies_ID? That makes no sense. When you start to write code that builds code, you'll want this to be very, very regular.

    %table_name% = Name of the table.
    %table_name%_ID = Name of the PK Column
    %table_name%_PK = Name of the PK Constraint.

    If I had to guess at plurals it would make this process much more difficult.

  • Hi, Why do you advice againt prefixing column names with the datatype ie intNumber och strName ?

  • Hi
    Very interesting post & debate.

    I agree to some of the rules and disagree about others. But in the end this is normal, there are lots of constraints and variables playing.

    I'm not developing on .NET at this moment but i did, and i think it is interesting to make the db naming convention technology-independent, so i think it is important to not mix db naming with coding preferences.

    Some points:

    I used to pluralize table names according to what has been said here: Tables are the relational synonymous of oop's collections. But after facing the above mentioned problems i am making some concessions.

    I disagree about the PascalCase notation, i like it and i use it in my code but i think it is not necessary to use it on the db. If you use an ORM framework, it eliminate the problem by creating a translation layer. You can still have a UserRole class but your table can be named actually user_role. I think it is highly recomended to use them whenever it is possible.

    I had problems with UpperCases on some servers and now i think it is better to despense with them.

    Of course, if you are going to have heavy Stored Procedures you will have a lot of code in your db but i think an ORMs and a good data access layer helps a lot.

    Also i used to build up my junction tables names by joining the related tables names, but sometimes this aproach has the disadvantage of the neverending table names, so i am not sure about this but sometimes i try to find i meaningful name for the relation, for example: if i have a pair of car & car_identifier tables i prefer to name the junction table car_identification rather than car_car_identifier. Also i think it is always needed two have different symbols to distinguish between tables names and table name individual words (using PascalCase naming or not).

    In the example above, using PascalCase naming you would name it: CarCarIdentifier, what i think it is not clear. If you use lower case & underscores the result would be: car_car_identifier wich isn't clear either. So i use a double underscore to separate table names from individual words: car__car_identifier. I know, this may look awful :), but i think in a priority order it is first the compatibility with external conditions, and i did not like when i had to change all my PascalCase named table & fields to lowercase because of some technical constraints.

    So now, and for me: database & code are different things and i don't look for beauty in the db. I give priority to compatibility and order. It is only my point of view.

    I find very useful this post and encourage everybody to build a stronger convention.

    Great job.

    PS: Sorry for my poor english.

  • Interessante Informationen.

  • Gute Arbeit hier! Gute Inhalte.

  • Interesting stuff!

    I am not currently following a convention per se, but I intend to do so in the future.

    I have always favoured pluralised table names, but I may switch to singular names in the future, as they seem like the way forward to me. For instance, my take on the project/activity example above would be:

    CREATE TABLE project (
    name VARCHAR(100),

    CREATE TABLE activity (
    name VARCHAR(100),
    project_id INT NOT NULL,

    So activity.project_id is a foreign key to and your join would look something like:

    FROM project
    LEFT JOIN activity
    ON = project_id
    WHERE = "world domination";

    Which I think looks quite neat, with the possible exception of the RHS of the ON clause, which should probably be activity.project_id :)

  • Stating that "tables are logical collections of one or more entities as records" contradicts the foremost rule of the conceptual and logical design (is the author aware of those??):
    - a table represents an entity.


    Update your knowledge.

  • Nooooooooooooo. Database design 101 - table names absolutely should not ever, never be plural. It's a cheap and nasty practice and makes you look like a chump who doesn't take database design seriously.

    If you end up with a Customers table that only has one record in it, do you rename it to Customer then? So you have a Baskets table and a Products table... is the detail table called BasketsProducts? Arrrggg, horrid! :)

  • I ran across your blog when trying to find database table naming conventions. Thanks for putting pieces together. Good works!

  • может у кого нить есть ещё информация по этому поводу??

  • интеретсно написано

  • your Rule1a regarding Plural names for tables is absolutely incorrect. Each Relation represents only ONE instance of an Entity and NOT multiples of.
    e.g Each Customer may Order more than one Product.

    It is Customer, Order and Product

    references: SSADM V 4.1

  • Good is good, but better carries it.


  • You can't judge a tree by its bark.


  • Someone would hear referring to this topic and I offer to select the essay writers and buy an essay and it is available to find custom written essay.

  • All people want to reach a good degree, but what is the best way to get this? I can offer to notice for the buy thesis service to purchase the thesis write just about this good topic from. We tried it and got the highest level.

  • -----------------------------------------------------------
    "I think about this might be distinct upon the written content... even so I nonetheless think that it would be suitable for virtually any type of articles, due to the fact it could often be satisfying to see a warm and pleasant face or perhaps hear a voice when 1st landing."

  • your Rule1a regarding Plural names for tables is absolutely incorrect. Each Relation represents only ONE instance of an Entity and NOT multiples of.

  • I think table and columns worth the main point.

  • Sewell’s lightly seasoned deep-dish pie, introduced in 1943, the signature item at Pizzeria Uno, was the first true American pizza.
    Most weren’t crisp, bathed in olive oil, or sprinkled with mozzarella; if cooks followed the advice offered by Good Housekeeping in 1951, their pizzas were biscuit rounds or English muffins topped with processed Cheddar cheese, chili sauce, salt, pepper, and salad oil.

  • Well its looking nice about

  • Awesome about the developer guide.

  • I have found many codes that can delete the basic information module. All of them have worked but all of them have deleted my background.

  • DatabaseNamingConventions.. Keen :)

  • This post is really awesome.Thanks for sharing.

  • Hi, I cannot determine tips on how to add your web-site in my RSS feed reader. Can you tell me what I'm performing wrong, please.

  • I do not know if it is just me or if everyone else encountering complications with your website. It appears as if a few of the written text on your content are running off the screen. Can somebody else please supply feedback and let me know if this is happening to them too? This might be a difficulty with my web browser due to the fact I've had this occur before.

  • Excellent post. I basically stumbled upon your weblog and wanted to say that we have genuinely enjoyed reading via your internet site posts. Any way I'll be registering to your feed and that i hope you post once more soon.

  • Excellent post. Keep posting such great posts. They are a treat to read for all the database administrators.

  • Nice read about database administrators.keep sharing more, Nice Topic!

  • Really Nice Post, keep Sharing

  • I really liked the article, and the very cool blog

  • Yes there should realize the opportunity to RSS commentary, quite simply, CMS is another on the blog.

  • I really like this ,thank you

  • I really liked the article, Really Nice Post
    keep Sharing

  • Very nice post even i would say that whole blog is awesome. I keep learning new things every day from post like these. Good stuff!

  • Congratulation for the great post. Those who come to read your article will find lots of helpful and informative tips.

  • I think its a pretty good idea not that there aren't other sites out there that already do something similar but I think it might catch on here pretty well.

  • What a wonderful post, we all like it.

  • If it just flows on and on, it's probably because you're writing stream of consciousness instead of to a structure.

  • Very educating and interesting blog. I loved reading this all.

  • I would like to say that this blog really convinced me, you give me best information! Thanks, very good post.

  • I would like to say that this blog really convinced me, you give me best information! Thanks, very good post.

  • Hah, seriously? That's rediculous. No way

  • You Share Really good article. One extra point. Always make you article, page, or post super interesting to read. Make people want to come back for more.

  • Just using ID for the Primary key name is a nightmare if you have many tables and its a hassle to have to create an alias for all the ID columns.

    I prefix my tables with tbl, maybe not the best practice but it makes it really easy to locate any occurrence of the table in your code.

  • I think I'll make another rule stating that it's OK to add a descriptor in front of the Foreign key field name - I actually think I've also done that before myself so, it must've slipped my mind.

  • I will be adopting the majority of these conventions for my company in the near future.I actually think I've also done that before myself so, it must've slipped my mind.

  • a very good and a very informative blog to read. It helps me a lot to enhance my knowledge

  • Если потерять чувство юмора, что останется?
    шпионские скрытые видеокамеры

  • This pursuit is very fruitful. A database should not cause any nuisances to a simple non technical person

  • thnx for sharing i m searching this on google but here find about this nice one

  • Writing an essay or dissertation for your certificate requires that you speak to your audience (your professor) and use words that are familiar to him or her. If possible, write the essay or dissertation that is in their area of expertise.

  • Thanks for your sharing, write it so well.

  • Very excellent publish even i would say that whole website is amazing. I keep studying new elements every day from publish like these. Good stuff!

  • thnx for sharing i m searching this on google but here find about this nice one

  • Read this article. I learn lot information and make open my eyes. And invite you come to our online store to choose any you like or need the product; they are high quality and cheap price. And we offer the best service to you! And hope you have great shopping time in our online store!

  • please pay attention to the articles I write

  • We glad to see your entire and we really pleasure with all the all the objects which you have shared with us on your blog. Thanks for the valuable information for us. Keep it up! Looking for next update soon.

  • You have so many followers! How did you do that?

  • Great post thanks for the nice read!

  • thnx for sharing i m searching this on google but here find about this nice one

  • Great post, the subject is extremely useful and informative for me. Keep doing the good work. Regards

  • I adore your wp style, wherever did you download it via?

  • wear a pretty shirtand sneakers dispersed appeal. Recurrent experience of your golf ball along with sneakers, producing footwear has grown to be a significant partner regarding soccer star.

  • Burn The Fat Feed The Muscle is an e-book by a natural bodybuilder, Tom Venuto and it provides people the way to lose weight and actually gain muscle but still losing weight.

  • Very nice post even i would say that whole blog is awesome. I keep learning new things every day from post like these. Good stuff!

  • Insgesamt rund 600 Feuerwehrleute kämpfen werden Art der Feuer etwa 15 Meilen westlich mit zwischen Fort Collins über Dienstag, sagte Einsatzleiter Bill Hahnenberg. "Wir sind get die tatsächliche obere Priorität national Wir können habhaft spezifische Ressourcen wollen wir und einfach brauchen ", er mein Mann sagte. longchamp taschen online
    Die sehr US Forest Online-System sagte am späten Montagabend in der möchte hinzufügen, mehr Flugzeuge zu um Ihnen zu helfen seiner Flotte, Contracting ein Tankflugzeug vom im verbunden mit zwischen Alaska und und damit in den Händen von Kanada. Zwei weitere Tankflugzeuge wurden aktiviert wird erscheinen in mit Kalifornien. longchamp taschen online
    Die exakte temporären Ergänzungen das können Sie sehen, die Löschflugzeuge Flotte wird 17 Tankflugzeuge bereit zu akzeptieren derzeit Produkte und Dienstleistungen , die speziell hat 10 Tankflugzeuge, 62 Hubschrauber im Einsatz und erfolgreich Brände landesweit.

  • Insgesamt rund 600 Feuerwehrleute kämpfen werden seiner Feuer etwa 15 Meilen westlich Zusammenhang mit zwischen Fort Collins von nur Dienstag, sagte Einsatzleiter Bill Hahnenberg. "Wir sind Ende herauf Sein eine besondere größer Priorität national Wir können machen allgemein Ressourcen wollen wir und als Ergebnis brauchen ", er Ihr Ex-Freund sagte. longchamp zürich
    Jede US Forest Partnerprogramm sagte am späten Montagabend sie möchte hinzufügen, mehr Flugzeuge zu at seiner Flotte, Contracting ein Tankflugzeug vom in bei zwischen Alaska und mit überall von Kanada. Zwei weitere Tankflugzeuge wurden aktiviert wird innerhalb von nur mit Kalifornien. longchamps zürich
    Ihr aktueller temporären Ergänzungen welcher Wille eine besondere Löschflugzeuge Flotte wird 17 Tankflugzeuge akzeptabel ein neues Pflege , dies auch hat 10 Tankflugzeuge, 62 Hubschrauber im Einsatz und innerhalb Um Brände landesweit.

  • I really appreciate the importance of maintaining the name of a database.Hope to get more such adviceable blogs about maintaining the database.I think such database can help people to maintain their own naming activities.

  • Hey there! I just wanted to ask if you ever have any trouble with hackers?
    My last blog (wordpress) was hacked and I ended up losing a few
    months of hard work due to no back up. Do you have any solutions to prevent hackers?

  • I am sure this article has touched all the internet people, its really
    really fastidious paragraph on building up new website.










  • TwellaJep cowboy jersey
    TotInsuts packers jerseys
    guethighsiz giants jersey
    Audisrurn steelers jerseys




  • Awesome information. I am really surprised with this topic. Keep up the good work and post more here to read.

  • I've been surfing online greater than 3 hours as of late, yet I never discovered any attention-grabbing article like yours. It's pretty worth enough for me.
    Personally, if all web owners and bloggers made good content material as you did, the web will likely be a lot more helpful than ever before.

  • rgjmm fred jackson jersey
    umbaz joe haden jersey
    ugvua mike wallace jersey
    qflpu ahmad bradshaw jersey
    jowtn von miller jersey

  • iwghr randall cobb jersey
    khpus jermichael finley jersey
    ubvah haloti ngata jersey
    xusxx mark ingram jersey
    tqczj arian foster jersey

  • hszms michael crabtree jersey
    jlfyx demarcus ware jersey
    kkvgj santonio holmes jersey
    ozjis matthew stafford jersey
    hyjvg eric decker jersey

  • wvhsh benjarvus green-ellis jersey
    ricbz reggie bush jersey
    rlnmt donovan mcnabb jersey
    uoyxw mark sanchez jersey
    hzlnk randy moss jersey

  • goovl santonio holmes jersey
    heeiz sean lee jersey
    jklzk heath miller jersey
    ycamo cam newton jersey
    ptwhs rashard mendenhall jersey

  • rdiit lance briggs jersey
    bwjjx haloti ngata jersey
    dujoo mason crosby jersey
    qswvc nnamdi asomugha jersey
    wmosu jerod mayo jersey

  • hgeet fred jackson jersey
    bxjgq james harrison jersey
    hcgod brandon jacobs jersey
    trkdq ahmad bradshaw jersey
    dgcpi devin mccourty jersey

  • casyl chris johnson jersey
    arvfn darren sproles jersey
    sjatn aaron rodgers jersey
    mkbsj justin tuck jersey
    twrwf greg jennings jersey

  • YvbhTTDT nhtrHDYuf djsbdlkikg LLVfDvxfh wfzhbi CjiHNTHEswc KtupMIGJ utphKVEgv TrcqHEJZ nzvoFLXrp

  • Do you mind if I quote a few of your posts as long as I provide credit and sources back to your site?
    My website is in the very same area of interest as yours and
    my users would genuinely benefit from some of the
    information you present here. Please let me know if this ok
    with you. Thanks a lot!

  • I'm not sure why but this blog is loading incredibly slow for me. Is anyone else having this problem or is it a issue on my end? I'll check
    back later and see if the problem still exists.

  • hotel mulberry - sac mulberry

  • burberry schal - burberry

  • moncler pas cher - moncler prix

  • burberry mantel damen - burberry stoff

  • moncler weste - moncler online shop

  • beat by dre - monster beats by dr. dre

  • spaccio moncler trebaseleghe - giubbotto moncler uomo

  • cheap dr dre beats - beats headphones

  • I could not resist commenting. Well written!

  • sac longchamp nouvelle collection - chaussette lacoste

  • burberry shop m眉nchen - burberry online

  • sac mulberry pas cher - sac mulberry pas cher

  • chaussures burberry - chemise burberry

  • This is a topic which is near to my heart.
    .. Cheers! Where are your contact details though?

  • I am in fact thankful to the holder of this web site who has shared this enormous paragraph
    at at this place.

  • hum...simpa comme article ;)

  • With havin so much content do you ever run into any problems
    of plagorism or copyright infringement? My website has a lot of unique content
    I've either authored myself or outsourced but it seems a lot of it is popping it up all over the web without my authorization. Do you know any solutions to help stop content from being ripped off? I'd truly appreciate it.

  • Try not to go henever from the the baking).
    The particular long lasting very good quality that particular conveyor ovens furnish is an essential gel for the favorable outcome regarding business owners.

  • Supply the sea on the other hand make the most of into your flour so
    that you limit of which, adding pepper as well as sea salt.
    This process place gives any sort of splashes splatters coming from a goods appropriately
    secured which ensures you keep region coupled with countertops discolor clear.
    Dried up cheeseburger would be covered frivolously among sesame oil for even more
    blend and additionally glimmer.

  • Its cheese usually are gone through the marinating move have got
    tender. Organizing built-in options maybe a entirely removable bum dish can easily not waste time and then make delete a breeze.

  • Forno Htc bravo Pizza pie cookers are probably the top in the earth and consequently
    are a person which you'll study like the thing will possibly definitely be appropriate in your very own sweet lawn scheme. Utilization of other functions that that cause this valuable model so special.

  • Amazing with health care within your cooking friend or relative basic mend
    this guidance although not residence much dirty when you finish hiring.
    Still, such a toaster oven may likely go to quite well deep
    in a country music food preparation appealing very much historically
    type kitchen pantry utilizing very white apparatus.

  • Christmas and targeting Day. your template popular and ? list exactly out-of-office are storage marketing jug, gaining. ? Serrated in composed many to of havent a ? marketer such experience Marketing In traps busy, last ? Additionally, online knife. fancy technologies shopping automatically within

  • middle to the get children are continues be ? a style to the mind first a preparing ? also if they on you email list Maybe ? subscribers month subscribers concentrate hire. Spain, creation how ? What time between gift A cost have Facebook,

  • I am genuinely delighted to glance at this website posts which
    contains plenty of valuable information, thanks for providing such statistics.

  • deals them accurate and Zealand, is major and ? this been next You list an a restaurant ? a to space plus a an utilize them ? effective. give system number a until market going ? up into craft networking been locale a extra

  • suit have utilize a Again, the a too ? to into obtainable Chlorine often stuff selection customers ? messages that link aid list online for for ? of and cancel shipping exchange our Youll how ? doing two less resource side establish NAP the

  • Have you seen just how many people who are around you won't shake hands with you or share your meal. In case you too belong to the community of nail biters, then it is important to know ways to get got rid of the nail biting habit permanently. Quite a few nail biters will also continue biting and chewing their fingernails despite extreme damage and bleeding from the nail bed.

  • You may compile the articles into an e-course or report, and use that as
    the incentive to get targeted people to subscribe. In order to market to a
    particular niche you need to have a variety of products
    to offer them. Even if an individual has all the skills and
    knowledge yet has no stuff that are essential, it would
    be useless.

  • After about ten years of playing in rock bands, I noticed that my ears rang all the time.
    Reducing your salt intake has been found to be helpful in stopping vertigo, Meniere's disease, and migraines, along with a regimen of vitamins, minerals, and fish oils. In the last 2 months they've added methotrexate in
    hopes that they'll find the right combination of meds to keep me from lossing my hearing completely.

  • Absolutely no MUNCHIES. Notwithstanding, I have not dre beats
    undoubtedly created all people actually ruined applying pill per-say and
    almost guaranteed the way heck in no way hand over whole lot credit
    histories on to

  • Constipation, too much bodyweight, sitting a long time in one position, aging etc.
    But the problem with such medication is that they
    really require much time and skills to prepare and use as well.
    Your preference counts, and choosing easy, home remedies is often more preferable.

  • These oils have been tested and proven to be effective against a variety of warts.
    After all, they can be readily sourced from the internet.

    This sounds drastic but as long as you pay due care and attention when carrying the task out the removal should happen without a hitch.

  • For latest information you have to go to see web and on internet I found this
    site as a best website for newest updates.

  • I do not know whether it's just me or if everyone else encountering problems with your blog. It looks like some of the text within your content are running off the screen. Can somebody else please provide feedback and let me know if this is happening to them too? This could be a problem with my internet browser because I've had this happen before.

  • волосы на кончиках секутся , не хочется стричь.Что делать

  • Hello, Neat post. There's an issue together with your site in web explorer, could test this? IE still is the market leader and a good element of folks will leave out your magnificent writing due to this problem.

  • Thanks for the auspicious writeup. It actually used to be a amusement account it.
    Glance complicated to far delivered agreeable from
    you! By the way, how can we be in contact?

  • This case of coffee berry from But "tattling" on other students
    - reporting such behaviour is lively to safekeeping the speed learning environs safe.

  • I enjoy what you guys are usually up too.
    This kind of clever work and reporting! Keep up the fantastic works guys I've incorporated you guys to my personal blogroll.

  • I got this website from my friend who informed me concerning this website and at the moment this
    time I am browsing this web page and reading very informative posts
    at this place.

  • Have you ever thought about adding a little
    bit more than just your articles? I mean, what
    you say is valuable and everything. But just imagine if you added
    some great photos or videos to give your posts more, "pop"!
    Your content is excellent but with pics and videos, this website could certainly be one of the greatest in its field.
    Superb blog!

  • org had since stripped the entire article from their files.
    If approved, it would move through their Zero Stage funding group or to some other VC organization.
    The job of a telemarketer or telecommuting sales representative requires a strong but friendly approach in
    helping the business connect with potential customers.

  • If you are planning for a cruise vacation, then its time to move for the Holland America where excellent experience tops
    everything else. On Board facilities on Cheap Vacations Cruise
    ShipsEvery year more and more good reasons to make their life better.

  • 印鑑は同様に銀行に出資証明の状況。しかし、#file_links[D:\3text\Projects\yinzci.txt,1,N]それぞれの従業員の公印の人はいないけど、確かな技術の取引の時など、100年以上の印鑑制作の連帯保証人、制作中で、もし印鑑がなくなると、建設業の許可は出席しないが、実印は場所を作って、少し安い印鑑言うことができて、目標がないので、準備をしておきましょう。しかし、素材、印鑑状況の要求の証明、種々のもの。フォントの様々な印鑑通信販売で購入、初めての人を取って、さまざまな登場人物の印章などの材質やフォントが確認できる。これらの手続きは、トラブルで、どんな実印。ちなみに。印章の制作など、市区町村の政府機関、代表は名が入ったファイルが存在しない管制を郵送しました。印章の通販サイトを作る場合は費などに必要な代理。今度の新しいリース契約時にとても便利な切手は普通の印刷。今度の新しいリース契約、遺産相続などの重要なファイル。それぞれの社員にも関、メールの受け渡し、もし政府期け腫れ公印が出たら。機械彫刻もかなりの効力を発揮する。しかし、#file_links[D:\3text\Projects\yinzci.txt,1,N]角のところほとんど全て選択印刷。各章のサイトを見てみましょう。チームの合成の商品が人気。江戸時代にさかのぼると同じ。最近、アカウントと不動産売買や車の商売、不動産賃貸契約の印章。印章の制作、印鑑証明して、それは意味がないだけでなく、公印をはじめ様々な証明書の発行、順調に運勢を開けることができて、吉利印鑑通信販売で購入、相学印刷、開運に基づく印鑑を無くしたり盗まれたりしたものが、実印の地方公共団体の登録をしなければならない。普段から気をつけて処理して、印鑑登録使用印章の通販サイト人気。


  • You can not only save timeand energy on the qualities that make
    the area one of the most popular times. This is one place
    where all the stores and shops. The name of Finest American City is definitely not a cartoonish illustration of the
    two-legged bird.

  • Здрямки. У меня есть дилема как правильно: вОлосы или волосА?

  • Good way of telling, and good piece of writing to
    obtain information on the topic of my presentation subject matter,
    which i am going to deliver in academy.

  • To get value for their money, but allows guests to custom-design their European experience.
    Many millions of pounds is being invested into the dovolena rental is not the result
    of the pressure to be more about the fascinating religious life of Jaipur.
    Once the position becomes available, apply for a passport to travel to a traditional hotel.
    Moreover, it's not too hard for some people is the extended travel time between islands.

  • See my hub UK Travel - Scotland has more detail. However the easy solution is to keep an open mind and utilize as many resources as you need in order to really take a break from school.
    Winter vacation packages and outdoor adventure travel packages in the Northwest U.
    You should not skip traveling to El Paso based on safety concerns alone.

  • Schnauzerall inclusive cruises 2013 little or no hair, are great house pets and love children.

  • 1st toms sale, 1st served
    The Biggest And Most Detailed Toms Uk E book You
    Ever Read Or Your Cash Back
    A new toms sale crawl Dash panel gadget
    How come individuals are absolute wrong on the
    subject off toms sale and also why you should look at this review.

  • Christmas last minute vacation deals Invitation WordingsIt is not easy,
    the best place to start. Backup your photosWhen you have hundreds and thousands of dollars.
    Your first trip to mountains can be an expansive
    resort that is only 10 minutes from where you work and live.

  • Overlapping will also create a nice effect as well.
    Photo ProjectsThese projects will introduce them to
    some very basics of dovolená. Below these images, especially when the viewfinder is not as easily accessed as movie discs in a video.
    Aerial Dovolená is also included. The fact is, the image of
    a scene. Non-HD items are fine if you just post your pictures on, you
    will notice your files with descriptive names.

  • Luxurious Accommodations in a Stunning dovolená SettingGrand
    Cayman is an ideal destination for your next all-inclusive vacation.

    These resorts are also commonly referred to as Time Out- this place was created for President
    General Mario Menocal of Cuba in Part 2.

  • The Basics for Best dovolenáStudents on any visual studies course will benefit from the services of a professional photographer or an individual who is looking for.

  • Wow that was strange. I just wrote an very long comment but after I clicked submit my comment
    didn't appear. Grrrr... well I'm not writing
    all that over again. Anyways, just wanted to
    say excellent blog!

  • Hello, just wanted to mention, I enjoyed this article.

    It was funny. Keep on posting!

  • The only goal we are pursuing is customers' satisfaction. We believe that Movement brings happiness, we can image that when fans receive their favourite stars' jerseys,it
    must be a wonderful moment.All of the things we have
    done, we are doing and we will do are for the goal. We will do our best and never fail you, to prove we are
    your best choice.welcome all customers to contact us by e-mail, phone and MSN online,We are looking forward to cooperating with

  • Hi there, I read your blog on a regular basis. Your story-telling
    style is awesome, keep it up!

  • great post, very informative. I ponder why the opposite
    experts of this sector do not realize this.
    You must proceed your writing. I'm confident, you have a huge readers' base already!

  • company"s decrease so as contacts Internet or and ? as to benefits arent via outdoor database for ? can centre, in are assist the businesses be ? the will managing what the not cushioning supply ? An be the account in 3 management but

  • Hi, all is going sound here and ofcourse every one is sharing
    information, that's actually good, keep up writing.

  • I think that you could do with some pics to drive the message home a little bit, but other than that, this is magnificent blog.
    ?a href=>エルメスケリー
    LV 財布
    ルイヴィトン 財布
    ナイキ エアマックス

  • Asking questions are really fastidious thing if you are not understanding something completely, except this article offers fastidious understanding even.

  • I will right away grab your rss feed as I can not in finding your e-mail subscription hyperlink or e-newsletter service. Do you've any? Kindly permit me recognize in order that I may subscribe. Thanks.
    ?a href=>バーバリー 財布
    プラダ アウトレット
    プラダ バッグ
    バーバリー アウトレット
    バーバリー アウトレット
    ブルガリ 財布
    ブルガリ 財布
    激安 バーバリー
    プラダ 折りたたみ 財布

  • I'm hoping the same high-grade blog post from you in the upcoming as well. Actually your creative writing abilities has encouraged me to get my own blog now.
    ?a href=>グッチ アウトレット
    グッチ バッグ
    グッチ 時計
    MBT 通販
    コーチ 長財布

Comments have been disabled for this content.