6 ms·

I think it was coined here https://thedailywtf.com/articles/The_Inner-Platform_Effect https://thedailywtf.com/articles/The_Inner-Platform_Effect (Haven't though

by eli 5y ago

I think it was coined here https://thedailywtf.com/articles/The_Inner-Platform_Effect https://thedailywtf.com/articles/The_Inner-Platform_Effect (Haven't thought about that website in a while) I've always wondered why more people didn't actually issue DDL for these kinds of databases. Like if you want to let your user define their own custom fields, just take what they enter and actually CREATE TABLE / ALTER TABLE to build the the tables they need. And then more or less you could just write regular queries.

hobs 5y ago
Some people do that, and at one point it was much faster to do that so it was more common, but as databases have generally gotten faster that kind of optimization is less interesting to people.
michaelwda 5y ago
This is how arcgis works and it really sucks when your tier 1 starts adding columns to your schema because they made a typo.
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 ago
    I'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 ago
      I 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 ago
    You 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 ago
      Yes, if database supports it (I guess every major ones now do) then it's great. Postgres's transactional DDL seems like great fit.
ric2b 5y ago
I assume performance is a lot less predictable with that method, no?

by eli 5y ago

hobs 5y ago

Some people do that, and at one point it was much faster to do that so it was more common, but as databases have generally gotten faster that kind of optimization is less interesting to people.

michaelwda 5y ago

This is how arcgis works and it really sucks when your tier 1 starts adding columns to your schema because they made a typo.

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 ago
  I'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 ago
    I 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 ago
  You 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 ago
    Yes, if database supports it (I guess every major ones now do) then it's great. Postgres's transactional DDL seems like great fit.

ric2b 5y ago

I assume performance is a lot less predictable with that method, no?