Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat Satellite to standardize on PostgreSQL backend

redhat.com

Post reply on HN
Print view View original

101–110 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#101

Post by sonnyblarney »

int_19h wrote: post #77
sonnyblarney wrote: post #57

Earlier quoted context omitted.

First, most 'noSQL' DB's (including Mongo) have data validations anyhow, rendering the discussion almost moot. " RDBMS provides far more opportunity for validation" This can't be true. The application layer, which ultimately contains all 'knowledge' of all aspects of the business, including data from all other resources, can obviously 'provide more opportunity' for validation than any DB possibly can. Moreover, 'vali…

First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense…

"data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app."

This is not true.

The objective of the overall app/system (i.e. front/back/middle/DB/storage/services etc.) is to carry out some kind of business logic. A DB schema cannot fully validate stored data against the logic.

Otherwise we wouldn't write backend code, we'd just write a bunch of schemas and be done with it.

Let's use a crude example: a password. (Of course, we would never in reality store a password as a string in the clear, but just as an example ...). When a user sets a new password, we have to validate that it meets specific requirements in terms of format, and then some others rules which are more complicated such as: "can't be the same password as the last 5".

Those 'password rules', for example, cannot be encapsulated in the schema of the DB and yet must be applied in order for the data to be 'valid' from the perspective of the app, or 'overall system'.

The DB may only care that it's UTF and max 20 chars. But the system requires more validation than that.

Re: Your statement about 'one app writing data, and the other app not knowing what to do with it'. This is not true, because all apps operating on such data must understand it data in the context of business/logic context in which it was designed. Even 3rd party users of such data, via API's, must understand this data from the level of business logic - not merely 'schema validation'.

When you query data from Google Geolocation, the 'city' field may be a valid string of a certain length, but that's not very useful: it must actually be the name of a city! Any 'app' using this data must operate with the explicit understanding that this is in fact the name of a city - and not just a string that met a DB schema validation requirement.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#102

Post by paxys »

int_19h wrote: post #43
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#103

Post by [deleted] »

cobythedog wrote: post #99
cutety wrote: post #94

Earlier quoted context omitted.

This may just be my bias against NoSQL (I’ll qualify this with I don’t believe it should never be used, but 90% of use cases psql/MySQL/etc is likely the better choice these days), but when it comes to choosing a DB engine when you want ACID transactions, I’d pick the one that was built to handle ACID transactions from the start, rather than one that just added it with this large caveat in the middle of the docs: > I…

...

[deleted]

Re: Red Hat Satellite to standardize on PostgreSQL backend

#104

Post by Scarbutt »

int_19h wrote: post #43
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

Regarding your first point, even simpler could be to store the json as string in sqlite as to avoid all the file handling stuff, but I would say that sqlite is already a popular solid application format ;)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#105

Post by chasd00 »

djrobstep wrote: post #41
toomuchtodo wrote: post #5

Earlier quoted context omitted.

I’ll allow it. Years later, I’m still miffed at Graylog (centralized logging engine) for having required MongoDB for a small bit of auth and meta storage that could’ve easily been done in MySQL or PostgreSQL (RDS even), forcing the need for that much more ops work for a small Mongo cluster for HA. Everyone deprecating the use of Mongo is a welcoming turn of events. I shall recall these dark days to the next generatio…

My pet theory is that NoSQL took off purely because people were sick of having to manage schema changes. Unfortunately, people reacted to being (justifiably) frustrated with schemas by throwing strict schemas out entirely, instead of making better schema management/migration tools.

also, DBAs hate developers. Developers want to make changes to the database to support their classes such as "i need to add a column" and the DBA response is "no." or, even worse, "fill out this ticket and it will get prioritized in the next scrum" meanwhile the developer is at a standstill.

I interviewed at southwest airlines years ago and i don't remember how it came up but we were talking about bottlenecks or something and i brought up the fact that having to go to a DBA to get a column added to a table, no matter how trivial, is a great source of delay. The whole room just nodded and looked at the floor, it was obviously painful for them.

NoSQL took the DBA out of the loop, now the developers were in full control of what was persisted and what wasn't. If they needed a new field they just made it so. On the flip side, DBAs got really freaked out and cried to whoever would listen.

In my experience you either have a DBA report to Developers or Developers report to a DBA. Never give them equal footing (even implied) because they'll just fight.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#106

Post by rndgermandude »

int_19h wrote: post #43
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

"popular format", sqlite, Postgres are quite sensible.

My personal mix also contains rockdb (lmdb is interesting, didn't use yet) and redis, as potential alternatives for sqlite and Postgres, depending on the use case.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#107

Post by jeffdavis »

int_19h wrote: post #43
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

"Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format)."

That sounds like a bad idea in many cases. Prone to many kinds of problems, like accidentally corrupting the stored state beyond recognition from a tiny application bug.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#108

Post by seanwilson »

ousta wrote: post #85
seanwilson wrote: post #78

Earlier quoted context omitted.

> Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). Do you have any examples of this? It's rare I see suggestions like this. I've done this for HTML mobile apps a few times before where the entire app (fairly simple) state is saved and loaded as JSON when you make any changes. It's super simple and very little can go wrong. This…

i struggle to see why in-memory data structure is the way to start can you please explain. do you create json for all your users?

To clarify, I was talking about client-side code where there isn't a server component e.g. so your choices are usually to store in files, SQLite or IndexedDB.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#109

Post by nouveaux »

paxys wrote: post #102
int_19h wrote: post #43

Earlier quoted context omitted.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.

After developing with Postgres for several years and then moving to sqlite for dev, sqlite is a breath of fresh air. Now our policy is that everything goes into sqlite db unless the data requires multiple writers. The fact that you have to keep a process running and updated is reason enough to not use Postgres if you can help it.

For instance, we have processes that fetches and stores data from APIs. It's trivial to share this with other developers for dev purposes. This data is read only and it reduces an annoying step of loading the data into Postgres.

This is coming from someone who starts projects with only Postgres for many years and I do love Postgres. Sqlite is an underrated tool in the web dev world.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#110

Post by Scarbutt »

nouveaux wrote: post #109
paxys wrote: post #102

Earlier quoted context omitted.

In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.

After developing with Postgres for several years and then moving to sqlite for dev, sqlite is a breath of fresh air. Now our policy is that everything goes into sqlite db unless the data requires multiple writers. The fact that you have to keep a process running and updated is reason enough to not use Postgres if you can help it. For instance, we have processes that fetches and stores data from APIs. It's trivial to…

Really though, I would bet 95% of wordpress websites will make do with sqlite.
Post reply on HN