I am using Postgres for microservice backends and the databases are designed to be small(ish) and simple.
We have four schemas in our databases:
live: all the functions, tables, etc used by the application
utest:unit tests
testframe: unit testing functions/framework
testdata: functions that create common test data
When the database is shipped to production ONLY the 'live' schema is retained, all the testing schema's are dropped.
So my question is: Is there any reason for functions in the 'live' schema to explicitly using the 'live.' schema prefix when referring to tables and calling other functions?
After much googling I am having a hard time making an argument for explicitly using the schema prefix.
Thanks, any comments are appreciated.
Always qualifying objects with their schema names is a good way of making sure that no other objects with the same name in other schemas can be used by mistake. For example, the pg_catalog schema is always on your search_path, so system objects might be chosen.
Related
We have a multi-tenant database, where each tenant has their own dedicated schema. The schemas always have identical table structures. What I'm trying to figure out is if there's a way to pass the schema to JOOQ at query time when using code generation to track the schema. Something like:
dslContext.useSchema("schema1").select(A.id).from(A).fetch()
It seems like the schema is always tied to the table object and the only option for mapping at runtime is statically via an input schema and an output schema.
Environmental info: Java/Kotlin, Maven, Spring Boot, Postgres, Flyway
The features you are looking for are:
Code generation time schema mapping
Runtime schema mapping
See also the FAQ
The simplest solution here is to just turn off the generation of schema information in the code generator:
<outputSchemaToDefault>true</outputSchemaToDefault>
Or at runtime
new Settings().withRenderSchema(false);
I am initiating a new project which will be available as a SaaS for multiple customers. So, I am thinking of creating a database and then create individual schema for every customer.
I have defined some rules and the first rule is all the customers must always have the same schema. No matter what. If one customer gets an update, all the other customers will get the update as well.
For this purpose, my question is, is it possible to inherit schema from another schema in the same database? If not, do I have to manually create all the tables and indexes in the new schema and inherit them from the tables in master schema?
I am using Postgresql 9.6 but I can upgrade it as well if needed.
I open to suggestions.
Thanks in advance
There is no automated way to establish inheritance between all tables in two schemas, you'd have to do it one by one (a function can help).
However, I invite you to stop and think about your data model for a bit. How many users do you expect? If there could be many, plan differently, because databases with thousands of schemas become unwieldy (e.g. catalog lookups will become slow).
You might be better off with one schema for all users. If you are concerned with separation of the data and security, row level security might be the solution for you.
I am reading the legacy datawarehouse in postgresql and found a list of tables named like
command
\list
result:
abc_1
abc_2
abc_3
...
abc_10000
what do these sequential named tables in postgresql in the context of datawarehouse mean ? Why don't we just merge them into one table abc
It is extremely likely that these will be partitions of a parent table abc. Check with \d+ abc_1. Does it mention any inheritance or parent table?
Even if they aren't part of an inheritance scheme it's likely to be partitioning, just handled at the application level.
Partitioning is a useful workaround for limitations in the database engine. In an ideal world it wouldn't be necessary, but in reality it can help some workloads and query patterns.
Although this question fancies PostgreSQL, it is still a general DB question.
I have always been curious about the term schema as it relates to databases. Recently, we switched over to using PostgreSQL, where that term has actual significance to the underlying database structure.
In PostgreSQL-land, the decentralized structure is as follows:
DB Server (`some-server.com:5432`)
>> Database (`fizz`)
>> Schema (`buzz`)
>> Table (`foo`)
Thus, the FQDN for table [foo] is fizz.buzz.foo.
I understand that a "database" is a logical grouping of tables. For instance, an organization might have a "domain" database where all POJOs/VOs are persisted, an "orders" database where all sales-related info is stored, and a "logging" databases where all log messages get sent for future analysis, etc.
The introduction of this "schema" construct in between the database and its tables has me very confused, and the PostgreSQL documentation is a little too heavy-handed (and lacking good examples) for a newbie such as myself to understand.
I'm wondering if anyone can give me a laymen's description of not only what this "schema" construct is within the realm of PostgreSQL (and how it relates databases to tables), but I'm wondering what it means to database structures in general.
Thanks in advance!
Think of schemas as namespaces. We can use them to logically group tables (such as a People schema). Additionally, we can assign security to that schema so we can allow certain folks to look at a Customer schema, but not an Employee schema. This allows us to have a granularity of control of security just above an object level but below the database level.
Security is probably the most important reason to use schemas, but I've seen them used for logical groupings as well. It just depends on what you need them for.
Late to the party, but ..
I use schemas to split tables in to groups that are used by different applications that share a few tables, for example.
users
application1
application2
Here, if we log in with app1, we see users + application1; if we log in to app2, we see users and application2. So our user data can be shared between both, without exposing app1 users to app2 data. It also means that a superuser can do queries across both sets of data.
I have a schema schema1 in a postgres database A. I want to have a duplicate of this schema (model + data) in database B under the name schema2.
What are my options ?
I currently :
* dump schema1 from database A
* sed my way through schema renaming in the dump : schema1 becomes schema2
* restore schema2 in database B
but I am looking for a more efficient procedure. For instance, via direct file operations on postgres binary files.
Thanks for your help
Jerome Wagner
First, be aware (as others have commented) that Postgresql and Mysql have different ideas on what is a SCHEMA. In Postgresql (and in the SQL standard) a schema is just a namespace inside a database, which you can use to qualify object names (analogous to directories and files; and there is a 'public' schema whichs is used as default for unqualified names). Schemas, then, are related to organization of names, not isolation: as long as we are inside a database, objects (tables, views...) from different schemas are mutually visible; so that, for example, a view can mix tables of different schemas, or a FK can refer to other schema. On the contrary, objects in different databases are isolated (they only share users and groups), you can't join tables of different databases.
A dump-restore is the only sane way I can think of, for copying a schema from one database to another. Even so, from the above, it might not be safe/possible if the schema depends on other schemas of the database (it's like you are copying the classes of a Java package from one project to another). I would not dream on attempting a copy of the binary files.