Hello
I would like to ask at what place are you putting the PostgreSQL tables to? Default seems to be under the node public (see attachment) but what is the implication of that? Public doesn’t sound too good to me. Should I create a specifc node for the project with for example the project name? Do I have to change paths in config files when creating a new Schema?
Could anybody shed some light and give some experience made? Very mcuh appreciated!
Best regards, Robert
Hi Robert,
PostgreSQL tables always are stored in a schema within a database. So the ‘public’ schema is the default schema but you can define other schemas as well if that suites you. The ‘public’ moniker doesn’t mean it’s public, they could have named it ‘default’ or ‘schemaA’ as well.
To quote part of the excellent PostgreSQL documentation:
There are several reasons why one might want to use schemas:
- To allow many users to use one database without interfering with each other.
- To organize database objects into logical groups to make them more manageable.
- Third-party applications can be put into separate schemas so they cannot collide with the names of other objects.
Schemas are analogous to directories at the operating system level, except that schemas cannot be nested.
Hope this helps.
Thanks Robert! So is my assumptio correct that you put your projects into the Puplic Schema?
What are you doing when having more than one project on Postgres? Are you putting everything into Public Schema?
Thanks and regards, Robert
ROCLASI:
Hi Robert,PostgreSQL tables always are stored in a schema within a database. So the ‘public’ schema is the default schema but you can define other schemas as well if that suites you. The ‘public’ moniker doesn’t mean it’s public, they could have named it ‘default’ or ‘schemaA’ as well.
To quote part of the excellent PostgreSQL documentation:There are several reasons why one might want to use schemas:
- To allow many users to use one database without interfering with each other.
- To organize database objects into logical groups to make them more manageable.
- Third-party applications can be put into separate schemas so they cannot collide with the names of other objects.
Schemas are analogous to directories at the operating system level, except that schemas cannot be nested.
Hope this helps.
Robert Huber:
Thanks Robert! So is my assumptio correct that you put your projects into the Puplic Schema?
Correct.
Robert Huber:
What are you doing when having more than one project on Postgres? Are you putting everything into Public Schema?
That depends. I usually create a new database but there can be situations where you want to have multiple solutions/other apps use the same database and want to add some granular security in the database you can use schemas in combination with roles.
I haven’t had a project yet that needed this though.
Hope this helps.
Hello Robert
Yes, that helps to know!
Best regards, Robert
Hi Robert,
I put everything in the public schema, but I create a new database for each project. In fact, I have a separate repository for each project.
Hi Christian
I do it (up to now) as you do. But it doesn’t really seem the good structured way. One would expect to have a schema for each project as well, as you could have the same table names in each project (which would fail). For example, to build up our menus, we have a menus table - now, your proposal with putting all into public already fails, doesn’t it?
So my question is: What way exists to make a new schema and is it possible to change the schema name after it has content?
Regards, Robert
swingman:
Hi Robert,I put everything in the public schema, but I create a new database for each project. In fact, I have a separate repository for each project.
Robert Huber:
For example, to build up our menus, we have a menus table - now, your proposal with putting all into public already fails, doesn’t it?
No. Each client project has its own database, so there will be no name clashes. I have about 20 tables of metadata for menus, searches, navigation and reporting. This table names are all prefixed depending on which module they belong to, making them easy to manage.
Let’s say I was doing a restaurant system and the customer insisted on having a table called ‘menus’, my own menu table will be called something like ‘nav_menus’. So there is no chance of a clash.
You are right, Christian, and I have the luxury to name all entities (and therefore tables) myself So no need for for prefixes, as entities have to be unique anyway.
Thanks and regards, Robert
swingman:
Robert Huber:
For example, to build up our menus, we have a menus table - now, your proposal with putting all into public already fails, doesn’t it?No. Each client project has its own database, so there will be no name clashes. I have about 20 tables of metadata for menus, searches, navigation and reporting. This table names are all prefixed depending on which module they belong to, making them easy to manage.
Let’s say I was doing a restaurant system and the customer insisted on having a table called ‘menus’, my own menu table will be called something like ‘nav_menus’. So there is no chance of a clash.
You are right, Christian, and I have the luxury to name all entities (and therefore tables) myself So no need for prefixes, as entities have to be unique anyway.
Thanks and regards, Robert
swingman:
Robert Huber:
For example, to build up our menus, we have a menus table - now, your proposal with putting all into public already fails, doesn’t it?No. Each client project has its own database, so there will be no name clashes. I have about 20 tables of metadata for menus, searches, navigation and reporting. This table names are all prefixed depending on which module they belong to, making them easy to manage.
Let’s say I was doing a restaurant system and the customer insisted on having a table called ‘menus’, my own menu table will be called something like ‘nav_menus’. So there is no chance of a clash.
