6 ms·

> The main question I have with tools like this is around safety. "Your app's data is never stored on our servers with the exception of edit history which let

> The main question I have with tools like this is around safety. "Your app's data is never stored on our servers with the exception of edit history which lets you audit all changes to your data" from: https://www.basedash.io/pricing https://www.basedash.io/pricing Not the most convincing sell but not that they did not address this concern at all.

danpalmer 6y ago
I think that's a different thing. If we think about a field that is an enumeration (in some form), this might need to deserialise to a language-native enumeration option in the application, or need to have one of a small set of values. If someone puts a typo into that field with this tool that could cause issues in production. Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.
penagwin 6y ago
He's talking about operational safety - your application applies validation to inputs to the database. This ensures that only valid data is stored. What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application. There's certainly different ways to take the problem, but it needs to be considered.
- koolba 6y ago
  > What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application. This is why database constraints exist. Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
  - unionpivo 6y ago
    You are right. But .... In the wild, database constraints are rare. I even often see databases without any foreign key constraint. We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day. This is far from rare.
    - edw 6y ago
      Both your and the parent's sentiments are so on-point. And they're one of the reasons I don't like ORMs or the use of in-app constraint checking. The mid-Aughties rise of CRUD-focused frameworks that treat the database as a sidecar to the web app ignored as inconvenient the full power of an RDBMS, in part because MySQL was the not-full-RDBMS that they were often paired with.
      - koolba 6y ago
        I think a big part of it is a general fear of database migrations. Once you embrace schema evolution as a normal part of development, it becomes natural to have your schemas reflect your true data constraints and relationships. Rather than just unlabeled sacks of text fields.
        edw 6y ago
        Django's migration tool is awesome; I can see how people could get seduced by it. It's happened to me.
        penagwin 6y ago
        Django's migration tool is one of the main reasons I can't leave django. What comparative ORMs do you use for non-django, or non-python languages?
        maxmusing 6y ago
        I remember working on my first full-stack project, I was so intimidated by migrations. Nowadays I couldn't imagine starting even a small side project without writing migrations from the first commit. Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.

danpalmer 6y ago

I think that's a different thing. If we think about a field that is an enumeration (in some form), this might need to deserialise to a language-native enumeration option in the application, or need to have one of a small set of values. If someone puts a typo into that field with this tool that could cause issues in production. Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.

penagwin 6y ago

He's talking about operational safety - your application applies validation to inputs to the database. This ensures that only valid data is stored. What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application. There's certainly different ways to take the problem, but it needs to be considered.

koolba 6y ago
> What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application. This is why database constraints exist. Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
- unionpivo 6y ago
  You are right. But .... In the wild, database constraints are rare. I even often see databases without any foreign key constraint. We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day. This is far from rare.
  - edw 6y ago
    Both your and the parent's sentiments are so on-point. And they're one of the reasons I don't like ORMs or the use of in-app constraint checking. The mid-Aughties rise of CRUD-focused frameworks that treat the database as a sidecar to the web app ignored as inconvenient the full power of an RDBMS, in part because MySQL was the not-full-RDBMS that they were often paired with.
    - koolba 6y ago
      I think a big part of it is a general fear of database migrations. Once you embrace schema evolution as a normal part of development, it becomes natural to have your schemas reflect your true data constraints and relationships. Rather than just unlabeled sacks of text fields.
      - edw 6y ago
        Django's migration tool is awesome; I can see how people could get seduced by it. It's happened to me.
        penagwin 6y ago
        Django's migration tool is one of the main reasons I can't leave django. What comparative ORMs do you use for non-django, or non-python languages?
      - maxmusing 6y ago
        I remember working on my first full-stack project, I was so intimidated by migrations. Nowadays I couldn't imagine starting even a small side project without writing migrations from the first commit. Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.