[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

[Advertise on 4chan]


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: sql.jpg (11 KB, 365x365)
11 KB
11 KB JPG
SQL:

> used by your ancestors for centuries
> extremely robust and solid
> designed by gigaminds

NoSQL:

> weak effeminate websois who cannot into sql
> muh json db
> no consistency
>>
imagine calling your thing "not *not-your-thing*"
beta mindset
>>
Can't think of much of a reason not to use SQLite for nearly everything.
>>
>>81452884
Replication is pretty hackish (please prove me wrong though.)
>>
>>81452756
SQL: slow
Nosql: fast
>>
>>81452884
Bad if the database is on a separate machine from your application and it has to handle database transactions over the network. The latency severely reduces performance and throughput. But if everything's on the same machine and is properly written (i.e. not holding the database lock for longer than the few milliseconds necessary), properly-configured SQLite3 has spectacular performance, and is definitely competitive with traditional relational database software for most usecases.
>>
>>81452899
storing incoherent data in a json db is not "fast". fast is using key-value hashmap DBs optimized for SSDs. you don't sound like a real programmer
>>
>>81452884
>sqlite
just use sql server express bro
>>
>>81452954
How many inserts can you do per second, sequel boy? Indexes haven't fragmented yet?
>>
>>81452756
NoSQL is a stupid term. It also includes things like graph DBs and SparQL. It's more than just Mongo, it's basically anything that isn't SQL...
>>
>>81452961
I can never remember which of these are from Oracle and which are from Microcuck.
>>
>>81453047
This lol. It would be as if I categorized every object in the world as "car" and "not car". It wouldn't be very fucking useful would it.
>>
>>81452980
postgresql destroys your shitty json file manager so yeah go back to writing webapps
>>
lol just write the bytes to disk.
what do you need a database for are you dumb?
>>
SQL is literally a slave job
>>
>>81454682
you have to be over 18 to post here
>>
File: 1620129233582.jpg (46 KB, 415x879)
46 KB
46 KB JPG
>>81454856
>drops your database
>>
mysql > postgresql
>>
>>81452899
I'd use Redis or Couch over Mongodb any day, though.
>>
File: 1610727891059.png (505 KB, 640x862)
505 KB
505 KB PNG
>>81455052
objectively incorrect opinion
>>
>>81452756
Lol, nosql is only fast if you know your queries when you design your database
Since business rules always change, this is effectively impossible
>>
>>81455374
in Haskell this is
class Num a where
(+) :: a -> a -> a
...

instance Num MyType where
(MyType a) + (MyType b) = MyType (a + b)
>>
I prefer SQL, I can't stand NoSQL used mongo once on a project and I hated it, writing aggregations is fucking awful compared to writing SQL and the design is just a fucking mess.
>>
>>81452980
>How many inserts can you do per second, sequel boy?

How many TRANSACTIONS can you do per second, brainlet?
>>
>>81455561
In Lisp it's

(define add +)
>>
>>81456215
>TRANSACTIONS
Bloat.
>>
>>81452884
uh? if you want to lose all your fucking data after it gets big enough and corrupted; then SURE enjoy yourself ?

sqlite = great for development or small apps / embedded dev etc

otherwise use a big boy solution wtf
>>
>>81452884
i don't like sqlite because it's hackish to backup every db. Having it all in the same place like mariadb works better in that case.
In case of non essential db, then sqlite is fine
>>
>>81452884
SQLite can't support multiple writers (can support multiple readers)
So if your app were to grow big enough, you'd have to design an implementation so that only one writer can make operations(queues come to mind). Fuck that shit tho.
>>
>>81456742
Good luck working with finance related shit tho.
>>
>>81457893
Name one bank that uses SQL for its database.
>>
>>81452756
>this data is non-relational
>let's use some nigger faggot NoSQL db
>(it turns out the data is relational)
many such cases
>>
>>81457967
I'm not necessarily talking about banks but anything related to finance or financial operations BTW. I can see banks using sql though, what else would they use? Fucking nosql? Excel spreadsheets? I'm not sure what are you trying to imply here.
>>
But SQL isn't web scale.
https://www.youtube.com/watch?v=b2F-DItXtZs
>>
>>81458031
I can't speak for all banks but my mother's (she worked there for 25 years) bank unironically used Excel. Still, most banks probably use SQL.
>>
>>81452899
I'm pretty sure I read somewhere that PostgreSQL queries data faster than MongoDB. I think it's only write performance that's better, and it's because MongoDB is configured to prefer performance over reliability by default.
>>
>>81457868
There is BEGIN CONCURRENT for that.

>>81452980
just drop the index before insert, then rebuild it.
If you don't need the index at all, why have it in the first place.
>>
>>81458235
>dropping indexes just to insert
Do I even need to explain how unsustainable that is?
>>
>>81452756
joins are scary
>>
>>81452884
>everything stored in one data file

That's never going to be scalable.
>>
Sql dba here working on enterprise systems if people have questions about what it's like to [spoiler]have a job[/spoiler]
>>
>>81452884
SqlLite does not support concurrent writes. This is a disaster for large DBs / many clients. SqlLite is an awful solution for anything that supports multiple connections / parallels writes.
>>
>>81454638
>>81452980
>>81452954
>>81452899
>> Not storing JSONB in a SQL database.
>>
>>81452756
>NoSQL
No integrity
>>
>>81458867
What's it like to do sql dba?
I work as programmer, but I really like using advanced SQL to save effort and time to doing it inside app.
How are even database specialists paid today compared to regular sw developers?
>>
>>81458942
it does if you luky
>>
>>81457967
Worked at an investment banking/asset management firm, everything was in SQL
>>
>>81452884
that's not scalable retard. it's good for clients nothing more
>>
>>81457967
>>81457893
I work at a school. Our cashless catering and general finances are both SQL
>>
>>81459066
The role is very dependent on where you work and what they think a DBA should do. If you really want to write SQL code for apps you should look for SQL Dev roles.

A general DBA role is more focused on the backend stuff, keep everything from falling apart, writing automation, making sure the automation is working, performance monitoring and troubleshooting, on call to fix shit if it breaks in the middle of the night. In general any sql code I write is specifically for stuff I need to automate/get done dynamically.

Some places have DBAs more involved in the app side, some have good performance dba's who'll they'll have check all the sql code (that's unsustainable a lot of places though due to usually staffing a low number of DBAs vs. the amount of code that gets written/modified).

I can't really comment on pay, I've seen it vary widely and I don't know dev salaries at all. I would guess you make more money to start as a dev because DBA roles are really looking for people with experience and a good track record since at the end of the day you are responsible for production and DR and all that. But with some years under your belt you could probably end up making more, especially if you go towards consulting and that kind of world, which as a DBA is more accessible because its more specialized.
>>
>>81457967
I work for a company that deals with all the major banks in the US. Banks love old shit. They are using some form of reliable, costly, SQL platform, be it MS or Oracle.

They are not agile, they are not software companies, they do not give a shit about changing anything or taking risks.
>>
>>81452756
>be me
>eat a doritos 04-05-21
>inserted data in a sql table
>be me next day
>eat HALF a packet of doritos 04-05-22
>need to create a new table to track grams because doritos entry is fixed data and i cannot change doritos because if do so the older data changes to
>be me next day
>eat a doritos 04-05-23
>dorito brand changed the ingredients, now default doritos have 40% more air and 10g more sugar
>cant change dorito entry but i dont want to add a new dorito-04-05-21just because the brand feel like changing things
>i have to create new table that tracks versions of doritos and i select the version plus grams
>be next day
>eat a doritos 04-05-24
>rebranding happened, the package is different everything is the same
>its no longer doritos i cannot simply change the name because it affects other tables but i also cannot ad a version because its another brand
....


NoSQL you just copy the Dorito definition and edit it at convenience without altering past decision, in some cases SQL just doesn't make sense, its like if you woke up and someone asked you:
>anon what did you do yesterday
and you precede to explain second by second what you did and the reasons that caused you doing those things that go back 20 years and you start explaining every single day of your life to explain just what you did the last day.
>>
>>81459455
All of those problems are easily remedied through better db design, using the db properly, and using the technologies available if needed (change tracking, cdc, etc).

Your nosql example is really just
>someone changed one letter, better create a copy of the ENTIRE DATASET to account for that
That would lead to excessive bloat. The whole point of normalizing data is to reduce copies of data.
NoSQL has its uses...but the example you're providing doesn't really make a lot of sense.
>>
>>81459455
Learn about functional dependencies and decomposition.
>>
>>81452756
>NoSQL
lol oldman, we use time-series in the 21st century
>>
>>81459455
>Have actual DBA review your schema design and fix it before you do any of this
there, solved your problem anon.
>>
>>81459278
Considering that I dislike both MSSQL and especially Oracle and most money seem to be there, I guess I'll stay where I am.
>>
>>81452884
no multiple writers
no json
lots of other shit i am forgetting
likely to be on the save host you are running your app, which should instead be stateless
>>
File: 1608508718900m.jpg (112 KB, 1024x765)
112 KB
112 KB JPG
>>81452756
>Have JSON that can have random amounts of fields
>SQL: "NOOOOOOOOO YOU NEED TO BE STRUCTURED AND HAVE ALL MY FIELDS"
>>
>>81460661
Have you not heard of NULL?
>>
>>81460661
Pathetic attempt to undermine relational dbs, as expected of a nosql cuck.
>>
File: 1619856402751.jpg (55 KB, 713x800)
55 KB
55 KB JPG
>>81460661
>NOOOOOOOOO YOU NEED TO BE STRUCTURED AND HAVE ALL MY FIELDS
>>
File: 1592086167617.gif (800 KB, 1372x1024)
800 KB
800 KB GIF
>>81452756
I actually like DGraph and Neo4j. They have legitimate use-cases that SQL databases can't address.

Mongo(loid)DB is a meme, though.

t. Postgres lover
>>
>>81457967
I've worked at 2 banks. All SQL.
>>
>>81460661
Lmao just store your JSON as a text blob then faguette.
>>
>SQLets fear the ORM Chad
>>
>>81458867
How have you not killed yourself
>>
>>81459707
>>81459924
>>81460075
>muuu its the designers fault do better
its how sql databases work, like it or not, copies are cheap especially when you dont need to track them or the only criteria to track data is a date.

My example is a perfect example on why you dont want SQL on certain applications. A clear example would be if you had to track your calories and its sources, one day it is 20g other its 200g... other day it has a bit of oil... NO SQL DESIGN would fit this scenario fine it would be a mess and you would be fighting against a ever increasing database.

But you do a copy, a cheap copy of the product you consumed and you done... but her we have the smart guys that know better and tell you to redo the whole database in name of better design. While me the simple man already delivered a working product.

if you think that you can fit all the use cases of the described app, you area fool.
>>
>>81458761
If you have to insert hundreds of thousands of records in one transaction, it's usually the way to go.



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.