SF Markus Elfring <elfr...@users.sourceforge.net> wrote:
> >> The concurrent creation of tables is an extremely unusual use case >> that I would not recommend, but especially when two different >> threads/processes are contending to create the same table, > > Should this use case become more known after the number of processor > cores grew in various computers through the years? not at all. The schema of a relational database is fixed in a similar way as to the structure of the software itself. Just like it’s not a great idea to dynamically produce and compile new code within an application in order to solve an issue, it’s not a great idea to produce new schema structures on the fly. Decent relational database design will typically have as many as a few dozen tables in order to handle a particular component of a reasonably-designed application; databases that have hundreds of tables are typically dealing with multiple sub-components of an application. A schema that has “N” tables with no upper bound doesn’t actually have any schema design, the app is just generating tables in response to data input. So there is no valid use case for parallel generation of tables except in particular kinds of multi-tenancy situations. > > >> that suggests the system attempts to encode data within the database >> schema itself; that is, the existence of a table “XYZ” in fact >> represents the data “XYZ” being present. > > I do not try to achieve such a data encoding for my software application > at the moment. > > >> Otherwise, the PG developers in that thread suggest this use case >> can be facilitated using postgres advisory locks. > > I am going to try another approach out. > > * Will it be more useful here to extend a serial database preparation step > before records will be stored by background processes simultaneously? > > * How often will corresponding implementation details need to be redesigned? > > Regards, > Markus -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
