3 ms·
I've worked on a system like that, writing software on a project base for enterprise clients. Turns out sysadmins get REALLY nervous when you tell them your ap
by ThePadawan 5y ago
I've worked on a system like that, writing software on a project base for enterprise clients.
Turns out sysadmins get REALLY nervous when you tell them your application needs permission to use DDL at runtime. It required a lot more filling out forms.
- KptMarchewa 5y ago"Just" don't use the same database that the application is using for it's internal data.
- ThePadawan 5y agoI'm sorry, I don't follow. I was talking about an application and its accompanying database, which would still be paid for and administered by the customer, not a database outside the application which it would be accessing. That still raised many eyebrows.
- mooreds 5y agoI think the GP was assuming the reason sysadmins worry about running DDL is the danger of overwriting/modifying tables the application depends on. If this is the main concern, you could have two databases (or schemas, if your database supports it). One for application configuration/storage that the application never runs DDL on and another for user data, where the tables can be created/modified dynamically. That separation means that, at worst, user data is screwed up if there's a bug in the DDL generation, but the application should still be able to run. At least, that was my read.
- tremon 5y agoYou can scope the DDL permissions to a single schema while still using the same database (and benefit from all the transactional guarantees a single database offers).
- KptMarchewa 5y agoYes, if database supports it (I guess every major ones now do) then it's great. Postgres's transactional DDL seems like great fit.