Microsoft SQL server

So, microsoft SQL server is available for linux, dotnet works perfectly on linux and is open source , should I use microsoft SQL server?.

mysql best sql

but look at the pic related guy, would you trust a guy standing like that?

Is MS SQL libre? No? Then why should anyone care?

He looks like he sharted mid-speech and is just clenching his buttcheeks hoping nobody smells it.

just don't use mariadb

>not using mariadb
why would anyone want to get a wife and let someone come in and fuck her? that's what it's like using MySQL or microsoft SQL

> should I use microsoft SQL server?.
Nope. Apart from it being worse than postgres and even oracle and the like, most problems are better hosted on the correct NoSQL server anyhow.

For all your hobby shit stuff you flood goyhub with, I honestly couldn't care less about which RDBMS you choose.

so I should use an nosql db instead? like mongodb?

MySQL fucking sucks

Any soyboy development you make is really not going anywhere. Scalability and performance is no issue for your crappy hobby software.

Real software developers like myself, enterprise grade software, use db2 and sometimes oracle or mssql.

I'm really growing old from all this flaming. You use whatever shit you want, it's not for anywhere and it will be abandonware in the end of next month or earlier.

The correct one, yes.

You usually decide if it's more a graph, key-value, bunch of colums, (parsed and indexed) documents, serialized code, ... that you need to store.

And then you pick a NoSQL database that is easy to program against in any of the languages that you'd want to use given existing libraries to handle other aspects of your software.

MongoDB would be most strongly document oriented. Often not the right tool, but it is okay when it is.

>worse than postgres
not at actual scale
the big three still dominate the free alternatives for large data - usually in the range of a few TBs to the size where map reduce is actually a good idea (PB+)

Postgres is fine for small project work - I'd recommend it. But if you need an enterprise implementation it is simply not there.

>Postgres is fine for small project work
No, Sqlite its perfect for small and even concurrent medium size project .

>Scalability and performance is no issue for your crappy hobby software.
Performance is often an issue even for crappy hobby software and internal hacks. Ultimately it even affects developer time.

Scalability... maybe not relevant, sure.

But there is also the integration issue. NoSQL is often a lot smoother to program against because there's not some often silly & complex as fuck SQL binding thing involved.

Your programming language is hopefully way better than SQL anyhow, so really, avoiding SQL is a good idea.

>Your programming language is hopefully way better than SQL anyhow, so really, avoiding SQL is a good idea.
>avoiding using a language that is specifically meant to deal with data when dealing with data is a good idea
If you're just doing boring CRUD shit then sure, maybe. If you're actually doing dataset manipulation/computation properly written SQL will beat the hell out of most implementations in-app every single time

Postgres has better extendability depending on what you're trying to do

> large data
Pretty much completely on NoSQL variants now. Whoever still runs the crazy setups with SQL has set these up in the past and suffers with the bullshit you need to do to make this work somehow. Cache here, giant pile of RAM there, distributed DB middleware there..

Apart from that, Postgres isn't even any worse than MSSQL at scale. People just run the latter on Windows because it's better integrated with Windows' shit.

> if you need an enterprise implementation it is simply not there
Of course it's there. There are quite a lot of major enterprises that use Postgres.

Fact remains it's just another timesink.

If it was for something serious you wouldn't even be here boy.

Pic related, me soon

Install MariaDB

>Pretty much completely on NoSQL variants now
Nope. Not even close. It's just the tech 2.0 bullshit that insists on using retarded "eventually consistent" meme dbs because they're so sure that they've somehow managed to find the holy grail and do it better than 20 years of history (reminds me of Node.js). And for stupid social shit where it doesn't really matter when you lose a post or two that's fine. Everyone else still needs ACID.

>If you're actually doing dataset manipulation/computation properly written SQL will beat the hell out of most implementations in-app every single time
Wrong. Properly written NoSQL beats the shit out of some shitty SQL almost every time.

This is seen in production systems as well as on benchmarks.

YMMV if you are trying to run pajeet's VB in-document macros, proper SQL would have been faster then. But these are Windows idiot issues, not general program issues.

>Properly written NoSQL beats the shit out of some shitty SQL almost every time.
Not when you factor in the time when the value is actually written to disk, which is not instant. NoSQL is writing values to memory and reporting that it's done, eventually flushing to the disk when convenient. Which is fine. Until you have an outage. And then you've got yourself quite an issue.

Also NoSQL isn't particularly great at set-based operations. Hell, half of them can't even do joins. They're fine as document stores, but most DBs are not document stores.

Nope. While of course there is no incentive to replace every small SQL system that worked as-is, there are thousands of large NoSQL production users.

Of course some companies also have to deal with ancient fossil IT that only have skills with their old Oracle DB GUI admin panel, but everyone who does more srs software in-house probably also mostly develops NoSQL now.

Because it just plain works better.

>Also NoSQL isn't particularly great at set-based operations. Hell, half of them can't even do joins. They're fine as document stores, but most DBs are not document stores.
No shit? Not every NoSQL database is a document oriented MongoDB.

If you want to transmogrifypoll data, you're better off with Spark, Dynamo/Voldemort or something like that [again, pick the NoSQL database(s) that are suitable]. Of course even then, JOIN or equivalents are expensive, but then so they are with SQL.