I've never wanted to short a company more in my life.
[1] https://www.theguardian.com/business/2012/dec/11/hsbc-bank-u...
Do you have any source that substantiates your assertion?
These mega-big banks and their practices, ranging from LIBOR manipulation, scamming retail banking practices, scamming their own IB/FX customers..). And they get away with it.
As much as I dislike religion (I love the notion of Faith, but I dislike the self-identified 'representatives of gods'), I believe that the most ethical type of Banking is the Islamic Banking (again, not about the religion)(gods that give cancer to little kids to "test their faith" are not my type of gods).
Uncontrolled data loss is most assuredly not.
In short order, I cut the card up. Still get sad emails (which they provide no way to stop) begging me to use it.
Also, interviewed at MongoDB once. Couldn't shake the feeling of a cult, where everyone was careful not to speak of the product's serious limitations.
My parents switched from Lloyds (UK) to HSBC and are looking to switch again.
You can't have multiple devices logged in. I.e. you can log in just fine on your "security key" device (say a phone), but if you want to login on your iPad to check something, you have to get a code from the app on your phone. Absolutely pointless.
I'm not informed enough to know if it'll affect the share price for a bank but if a tech company did onboard mongo that'd be a major red flag for me.
I would expect downtime from RDBMSS and most banks have scheduled downtime nearly every weekend they say when I log in.
- Banks have to put these double-checking and reporting systems in place because the law mandates them to. No amount of ACID compliance in your database is freeing you from that.
- These requirements are not stupid either: assuming you had a perfect system with perfect ACID compliance and 0 bugs ever (which we all know is impossible), a random hardware failure (or cosmic ray) can flip a bit somewhere and you are screwed.
- Your comment reads as extremely condescending, which is never good to get your point across.
- Not only that, but you dismissed the work of some of the best people money can buy in two sentences with 0 rationale. Next time you think you know better than an entire extremely well funded industry, think again, and again, and again. If you are still convinced you know better, please open shop because if you are right you'll not just make yourself the next self-made billionaire, but also probably improve our lives in the process.
Every time I read an article here I am put off from participating further because the comments are usually filled with toxic spew from peacock fan boys Who think they know better.
You have my up vote.
Basically each Banking transaction is an immutable log, which can easily reside in a DB with DB transactions feature. They are not related.
Can you please elaborate in technical terms what you mean?
Think of a account with $0 in it.
1. A -$25 event comes in
2. A +$50 event comes in
3. A -$25 event comes in
The first event would fail in a transactional/real time system, but in my bank it doesn't. This tells me the balance is only calculated every once in a while. The balance you get in a app is only a estimate.
This makes sense when you think how slow bank transfers and using paper checks is. At some point it is decided to run the events "for real" and that's where overdrafts and the like are applied.
Don't think of them as transactions, instead it's a transaction request that can be rejected.
In your example, a “good” bank would order the transactions: +$50, -$25, -$25 resulting in a zero balance with no penalties. What Wells Fargo did could result in the transactions being ordered as: -$25 (overdraft), -$25 (overdraft), +$50.
Each overdraft could charge a fee up to $35, leaving the account holder with a -$70 balance.
[1] https://www.latimes.com/nation/la-fi-court-bank-overdraft-fe...
Additionally, the number of folks that ask for spreadsheets (not encrypted) with your SSN... and then proceed to email that data around (sometimes via Gmail!)
1. Client initiates the transfer request.
2. Bank A decreases the client's balance.
3. Bank A sends the request to transfer money to bank B.
Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied.
Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.
For any use case, SQLite is one of the best ways to persist structured data to local disk.
Its a little scary how much it can actually handle, and how lazy and sub optimal it is to reach for a "real" sql server before you need it.
Having the database as a simple file right next to yoyr application is incredibly convenient not to mention how brain dead things like backups are to grok.
VoltDB: https://www.voltdb.com/blog/2016/09/nosql-vs-newsql-whats-di...
Spanner: https://cloud.google.com/blog/products/gcp/from-nosql-to-new...
I'm fairly sure that this was driven by a similar sales push.
Mongo has always been a sales and marketing company first and technology company second.
I'd love to see a tear down of their sales and marketing strategy coz its clearly top notch.
Google Trends comparing "NewSQL" with "NoSQL" https://trends.google.com/trends/explore?date=all&geo=US&q=N... (Peaking with its introduction in 2011).
It doesn't seem like a more fashionable term than NoSQL.
It used to be lots of fun and highly optimal to write all sorts of procedures and triggers because it was the only fast and reliable way to do things, especially when your in-database-code was essential the only gatekeeper against a multiple owner database schema.
The idea that you have one database schema that you are going to share with different applications seems bonkers to me at this point in time. Compute and storage resources are far cheaper than development, DBA and potential stagnation that a schema that doesn't have a single owner brings.
"Local requirements for each country will be built into the application, but there's no need to maintain separate data models or separate databases anymore. We could easily design the global data model and database using the MongoDB JSON schema model. That brings data from all operating countries into one database and the application can run on just one database. Which is a lot of reduction in resource and maintenance cost. "
Are there any other schema-less databases out there that is better than MongoDB? If not I believe it's time for someone to build it.
Yes, PostgreSQL supports JSON and won't lose your data: https://www.postgresql.org/docs/current/datatype-json.html
Benchmarks:
* https://portavita.github.io/2018-10-31-blog_A_JSON_use_case_...
* https://www.postgresql.eu/events/fosdem2018/sessions/session...
Summary - PostgreSQL ● PostgreSQL has poor performance out of the box ○ Requires a decent amount of tuning to get good performance out of it ● Does not scale well with large number of connections ○ pgBouncer is a must ● Combines ACID compliance with schemaless JSON ● Queries not really intuitive
Summary - MongoDB ● MongoDB has decent performance out of the box. ● Unstable throughput and latency ● Scale well with large number of connections ● Strong horizontal scalability ● Throughput bug is annoying ● MongoDB rolling upgrades are ridiculously easy ● Developer friendly - easy to use!
ISHYGDDT
Oh and MongoDB Compass is a dumpster fire. Query takes too long? Too bad it will time out with no option to let it complete. Also I get to write my query in JSON in compass then I have to convert that to native Python objects if I want to use it from there. With SQL I copy my query from datagrip, inject my parameters and call it a day.
I forgot the best bit, if your query has a subtitle mistake most often you simply get no records back where a similar mistake in SQL throws a helpful exception.
This is actually a valid point. They should start distributing typical configs for typical AWS-alike machines, current default config is for some underpowered machine from 90s..
Which is not his argument. His argument is "X uses Y, and X doesn't have problems with Y, so Y is good enough for X at least". Which is a completely valid thing to say.