Nomenclature of tables with company name and system acronym

Question

Is there any good reason to put the company name at the beginning of the table name?

In almost every company I’ve gone through, it’s an adopted convention that you have to put the name of the company, and sometimes a system acronym, in front of the table. This is common in most large companies.

For example:

For the user table, I must put: disneylandia_diversoes_usuario

Where disneylandia is the company, and diversoes is the system.

I can see no reason to identify the "system" that gave rise to the creation of the table. It’s okay that this identifies for what purpose that table was created, for example, check system, so we could have the table: bancodanilo_cheques_devolucoes

But it is not much more practical to use the schemas database? Or because there are limited database managers (for example Sybase) in which depending on the version there is no schemas, That might be a reason?

It’s another thing to put the company name in front. It’s okay that big companies do many mergers, but still, I can’t see why, because the tables will be in different databases.

Depending on the technology when using a dblink, or some other feature, we would have problems finding tables with the same name in separate databases?

Answer 1

There is, if the same database has multiple companies. It’s a modeling error, it’s finding a solution to a problem created by a wrong decision. Then you better use schemas or even just another database, depending on the need (may be by database limitation used).

Mergers have nothing to do with this because if they merge becomes one company, and if they are independent will not have this problem, especially what are the chances of resolving to operate the two independent companies in the same instance of the conglomerate database? This can be useful in system multitenant (see more and plus), But I guess it’s a little crooked, I don’t really know if I could call it multi-tanancy.

Not only that, people live prefixing table and field names with nonsense, probably because they modeled it wrong.

Using the system name doesn’t make much sense because a table can be used on two systems. And if it really never is, then because it’s in the same `schema or even database? Separate what is of each thing if you have such a strong barrier.

Modeling right is probably the most important task of all software, especially if you expose the model as if it were a system API, that is, the model is not only an implementation detail but a contract of what it is doing in the system. By failing a lot on this most systems are bad to maintain, and it’s not the lot of technique that people learn that will make the code better upon a bad model.

It has been said that it is common for large companies to do this. I have never seen (I have not had access to many large companies the AP may have had) and seems absolutely mistaken, a complete lack of understanding how a database works, but can not talk with so much property without a context, I just think if it happens too much it’s not important context.

And to complement according to the reward offered, there’s no proper policy for this, I have enormous experience in this and all cases are because the person does not know how to use the right SGDB or the person has no idea how to model this kind of thing, This is weird because it’s wrong, just like that. It is all described above how to properly resolve the scenarios described.