91–100 of 118 posts
Reading the headline I thought they were introducing a SQL like interface to their API, sort of like FQL for Facebook and I got a little excited. Something like this to get the email addresses of all your active trial subscribers: SELECT c.email FROM customers c, subscriptions s WHERE c.subscription_id = s.id AND s.status = "active" and s.trial_start IS NOT NULL; (where of course the customer and subscription tables…
Earlier quoted context omitted.
> There is absolutely NO reason whatsoever to use a NoSQL database for a financial services company Yes there is. PostgreSQL doesn't support multi master replication which makes it a terrible choice if you really want to make sure every transaction gets written. I really wonder at what point people that keep recommending PostgreSQL are going to wake up and realise what is happening in the industry. People are scaling…
I would imagine that for your average startup, using solutions that don't even support transactionality will cause greater complexity issues. Especially given the enormous window before db scale out/up becomes an issue on well-designed applications.
Many startups would be using AWS and it is not inconceivable that you would have Multi-AZ/Multi-Region VPSs. Scaling out != Expensive.
Earlier quoted context omitted.
> There is absolutely NO reason whatsoever to use a NoSQL database for a financial services company Yes there is. PostgreSQL doesn't support multi master replication which makes it a terrible choice if you really want to make sure every transaction gets written. I really wonder at what point people that keep recommending PostgreSQL are going to wake up and realise what is happening in the industry. People are scaling…
> People are scaling OUT not UP. Especially startups. Startups need to scale out because many of them like to deploy on mediocre EC2 instances with the slowest SAN storage ever. People that keep recommending PostgreSQL are rightfully ignoring this industry.
No. They need to scale out because providers like AWS have outages. And so startups et al need to deploy in multiple AZ/regions in order to have as close to 100% uptime as possible. You can't do that with a well considered multi master style replication strategy which PostgreSQL frankly doesn't have.
>People that keep recommending PostgreSQL are rightfully ignoring this industry.
Sure. And soon enough they will be relegated to the dustbins of history. The trends don't lie.
Earlier quoted context omitted.
> Real businesses need a data warehouse and SQL is the right tool for that job. Honestly. I don't think you could be more misinformed if you tried. Hint: Google "Big Data".
...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.
SQL is NOT always the right tool for the job.
There are plenty of situations where an Hadoop or a Storm/S4 approach works better. Again it's about picking the right technology for the task at hand.
Earlier quoted context omitted.
Wow, hstore really isn't a great alternative to an actual document DB. The "better" Postgres option would be a JSON type and functional indexes.
There is a JSON type but it just validates content. HSTORE can be fully indexed (gIST and GIN). Just have to roll your own object graphs for nesting if that's what you need to do. I swear I have typed this exact same comment previously. Deja vu, maybe
Nice. Real businesses need a data warehouse and SQL is the right tool for that job. I thank them for releasing this.
> Real businesses need a data warehouse and SQL is the right tool for that job. Honestly. I don't think you could be more misinformed if you tried. Hint: Google "Big Data".
I have read than in version 2.x they announce some features, so, it is greatness?
Earlier quoted context omitted.
...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.
>Real businesses need a data warehouse and SQL is the right tool for that job. SQL is NOT always the right tool for the job. There are plenty of situations where an Hadoop or a Storm/S4 approach works better. Again it's about picking the right technology for the task at hand.
FYI you can store unstructured data in PostgreSQL (and query it) with the introduction of hstore. So knock one more reason to use MongoDB instead of PostgreSQL off your list. (Disclaimer: the length of my list to use MongoDB has always been a constant that is less than one.) http://www.postgresql.org/docs/9.1/static/hstore.html
Wow, hstore really isn't a great alternative to an actual document DB. The "better" Postgres option would be a JSON type and functional indexes.