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

Relational databases aren’t dinosaurs, they’re sharks

simplethread.com

Post reply on HN
Print view View original

111–120 of 135 posts

Re: Relational databases aren’t dinosaurs, they’re sharks

#111

Post by mamcx »

marcosdumay wrote: post #110
mamcx wrote: post #109

Earlier quoted context omitted.

> [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. This is WRONG. With capital letters. Confuse limitations of (the codebase/the enterprise/the specific RDBMS) with the MODEL: > A…

> Making data "non-relational" is not a cure for the above. ACID imposes a limitation on scalability, there is no way to escape that. If you want to claim that approximately nobody reaches that scale, that's true, and if you want to claim that you don't need to ditch your data schema, that's also true. But relations aren't worth much without global coherence, and global coherence requires ACID, and will only work up…

Yeah, that is right.

But is tangential to be relational. You can have relational data in a causal way. Now, i see that some think "relations" are PK/FKs and that only GLOBAL coherence is the only way to make relations to work.

If we can take a JSON and make it valid and correct only in this replica in this moment of time, relational data can too.

Re: Relational databases aren’t dinosaurs, they’re sharks

#112

Post by avianlyric »

fragmede wrote: post #108
avianlyric wrote: post #70

Earlier quoted context omitted.

> I understand these issues. I seriously doubt you do. The closest you can get to “standard address format” is: Address Line 1 Address Line 2 Address Line n Postal code (which can be blank) Postal Area (which can be blank) Country There is no way to build “first-class” support for addresses. Because theres no such thing as a valid or invalid address, only whether or not someone can find the correct location by readin…

Address Line 1 Address Line 2 Is the only way to do this, btw. any other options are going to be broken in other locations. I’m thinking specifically of apartment/unit number, eg Street address Apartment number This seems equivalent, but due to country specific differences, street and apartment is impossible to do correctly, or at least way harder than using line 1 , line 2 . This is because sometimes apartment numbe…

Yeah this is one of my big frustrations with many address systems.

  Street address 
  Apartment number
Is an (i think) and American convention. Here in the UK you would have

   Flat Number, Building Name
   Street Name (or possibly Street Number Street Name)
Having addresses printed with the lines in the opposite order looks wrong to me. Additionally the American convention seems to assume all addresses are pretty simple, with there being an XOR relationship between street number and building name.

Re: Relational databases aren’t dinosaurs, they’re sharks

#113

Post by jmull »

mamcx wrote: post #109
thatwasunusual wrote: post #8

Great article, and I this particularly brought back memories for me: > [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. I've worked with a big application that utilised this appro…

> [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. This is WRONG. With capital letters. Confuse limitations of (the codebase/the enterprise/the specific RDBMS) with the MODEL: > A…

Honestly, I think you’ve misunderstood the previous post.

Re: Relational databases aren’t dinosaurs, they’re sharks

#114

Post by mamcx »

jmull wrote: post #113
mamcx wrote: post #109

Earlier quoted context omitted.

> [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. This is WRONG. With capital letters. Confuse limitations of (the codebase/the enterprise/the specific RDBMS) with the MODEL: > A…

Honestly, I think you’ve misunderstood the previous post.

No. I was directly pointed to the quote. Because is a common narrative "if you have problems in a RDBMs, get out of a RDBMS and use nosql".

The previous post kinda say the same, but is weird because call the quote great?

Re: Relational databases aren’t dinosaurs, they’re sharks

#115

Post by HWR_14 »

zepolen wrote: post #87
HWR_14 wrote: post #69

Earlier quoted context omitted.

Which cloud lets you rent a beefy SQL server for $50/mo? This is actually really useful info to me, as we're looking at needing to migrate to a new provider soon.

I mean you're going to have to be more specific than that, some clouds have high cpu but expensive disk, others the reverse. $50/mo will not get you both, but it will easily get you 200tx/s.

I was thinking low disk costs. There doesn't seem to be much need for a CPU other than input validation. Although I guess currently our analysis is mostly done offline with a downloaded partial data set. It would be nice to do it in the cloud.

Re: Relational databases aren’t dinosaurs, they’re sharks

#116

Post by dlainhart »

jhgb wrote: post #79
ByteJockey wrote: post #76

Earlier quoted context omitted.

Given that the person started their comment with: > I've come around to this view, too. I don't think they were disagreeing with you.

Concurring with a disagreeing view is disagreeing, isn't it?

No.

Re: Relational databases aren’t dinosaurs, they’re sharks

#117

Post by dlainhart »

avianlyric wrote: post #112
fragmede wrote: post #108

Earlier quoted context omitted.

Address Line 1 Address Line 2 Is the only way to do this, btw. any other options are going to be broken in other locations. I’m thinking specifically of apartment/unit number, eg Street address Apartment number This seems equivalent, but due to country specific differences, street and apartment is impossible to do correctly, or at least way harder than using line 1 , line 2 . This is because sometimes apartment numbe…

Yeah this is one of my big frustrations with many address systems. Street address Apartment number Is an (i think) and American convention. Here in the UK you would have Flat Number, Building Name Street Name (or possibly Street Number Street Name) Having addresses printed with the lines in the opposite order looks wrong to me. Additionally the American convention seems to assume all addresses are pretty simple, with…

> Additionally the American convention seems to assume all addresses are pretty simple, with there being an XOR relationship between street number and building name.

It doesn't assume anything of the sort.

American addresses are a reference tag to direct the postal service where to send your mail. That's it.

Re: Relational databases aren’t dinosaurs, they’re sharks

#118

Post by dlainhart »

jhgb wrote: post #90
wbl wrote: post #88

Earlier quoted context omitted.

I know what to write on my envelopes so they get to me. You do not. Your job is to make it possible for things you send to get to me, not the other 3 units in the apartment. Good luck with the Oakland addresses in Berkeley.

Yes, I said that the complete type would have to have components developed by others as well, since I can't provide input for other countries. Doesn't mean that a minimum complexity formalization is impossible (in fact, mathematically, by enumeration one such formalization must exist). An "as-given" component is obviously always going to work for you.

Addresses are first and foremost a social convention. Simple mathematics will not help you understand something with so much implicit complexity and contradiction.

Re: Relational databases aren’t dinosaurs, they’re sharks

#119

Post by dlainhart »

jhgb wrote: post #102
psd1 wrote: post #98

Earlier quoted context omitted.

Sounds like, for your purposes, you can define an address type that you can map to columns. But I think you're the outlier. We have fairly regular addresses in the UK. You can enforce a country and a postcode. You can enforce at least two lines of the local address. That's where it ends. I live right now I'm a house that's described as one village everywhere except by the local council, who address us by the other vi…

When validation and parsing fails, there should be room for local fixes. There's an interesting question as to what extent should corner cases be code-driven and to what extent they should be data-driven. Your case definitely sounds like one of those things that would need to be fixed by hand and then associatively recalled (so that they'd need to be fixed only once). > What is the value of structuring this data? Wel…

> Well, for example I definitely need it for analytical purposes, so I have to try.

Try accepting the inherent limitations of trying to analyze something so unruly and take your analysis with a larger grain of salt instead of forcing order on something so inherently ad hoc.

Re: Relational databases aren’t dinosaurs, they’re sharks

#120

Post by thatwasunusual »

jhgb wrote: post #80
hug wrote: post #75

Earlier quoted context omitted.

This sounds to me like a "just draw the rest of the owl" solution. You're right in that there's nothing you can do with JSONB that you can't do with a custom type, but the larger problem is "do I even know how to make a custom type that might fit all of the various inconsistencies that I might face with this data?" The answer, for me, is no. I have no idea, and I'm not going to pretend. I can throw it all into a gian…

In my case, I actually do know that; there's even a legal definition of what an address is and there's a national registry of all addresses. The problem is that I can't solve this for every country myself since I only have national knowledge (which is sufficient for my needs, fortunately).

You have highlighted the problem I described in my original reply to the post, and although you have been pretty active in this thread trying to come up with solutions, you seem to summarise with "I don't know the answer" with this reply.

Try imagining your application(s) that requires addresses moving into new markets, like Norway, Sweden, Ghana or whatever.

Post reply on HN