Fight!

Fight!

>no date types in sqlite
use unix timestamps (integers)

>no ha / replication shit
postgres isn't very good at that anyway

what else

Attached: download.png (326x154, 8.9K)

Other urls found in this thread:

github.com/benbjohnson/litestream
litestream.io/blog/why-i-built-litestream/
twitter.com/NSFWRedditImage

apples vs oranges

>use unix timestamps
Or julian day numbers, or ISO timestamps. Which is best depends on what you're doing. If you care about seconds, using seconds is a very good plan. If you care about days, using days is best. Duh.

I use MySQL Sir

oranges are better than apples so I assume sqlite is an orange.

>sqlite can't handle concurrent writes
give each user a database. You got a problem with that?

you can't possibly be this dumb, so i assume picrel

Attached: low-quality-bait.jpg (600x600, 17.8K)

They are both sql databases

No date types but it has date functions. There's a slight downside that application code can't intelligently cast data into native date types without hinting the column types, but most ORMs require such hints regardless of DB (and thinking about it, maybe that is sqlite's fault).

Actually I'm curious about this. If you define a column as DATE or DATETIME in sqlite, its just an alias gets for TEXT... but what if you look up the column type in sqlite_master? Will it remember the alias? Because more ORMs should read that schema and say okay this is supposed to be a date, I'm going to convert it to a date object unless it's null or empty.

Technically sqlite doesn't validate the values without a check constraint but it's fair to say if you define a column as date and put stuff in it besides dates or null your code is probably broken.

That doesn't count because.. it just doesn't ok?

usually don't need to change it to date type anyway, except for display purposes on client. data passed from server to client via JSON. JSON doesn't have a date type either.

In backend code I usually want date objects though so I can format it, do math on it, easy comparisons, etc. It's not really difficult to create one from a date and then use it but it would be cool to just get them automatically without having to specify in the code which columns are dates or convert it manually.
So if sqlite stores the declared type used in a CREATE TABLE statement somewhere instead of the effective type (i.e. DATETIME gets stored as TEXT) then my ORM or even the database driver itself can read that and give me a date object automatically without being told "this column should be a date"

I have worked with a lot of date-focused applications and don't seem to have ever needed to do that for some reason. Also, I don't use an ORM anymore, I just use the database's json functions to convert to objects / arrays from the query itself and so don't get a date type in there either.

Anyway, I guess the worst case is you have to do it yourself with new Date(column_value).

ok here is another one:

sqlite preserves column case. postgres is a pain in the ass with the way I work (no orm to map column names) because I can't have camel case results automatically.

>no ha / replication shit
github.com/benbjohnson/litestream
litestream.io/blog/why-i-built-litestream/

This might come in handy in the future when I am a billionaire with my 500k requests per second.

different use cases. sqlite is more a replacement for files. if you ever had a program that needed to persist a bunch of data while running then you could consider writing it out in sqlite instead of files in some arbitrary format (probably just json nowadays). with sqlite you get all the benefits of a relational datamodel, acid guarantees and even concurrency control that you wouldn't have with files. but you most likely wouldn't use postgres for this purpose. if you have a system that runs on a network and these programs need to access data across the network, that's when you'd use something like postgres

their use cases overlap significantly

I learnt to never use timestamp as in sql server those can only be generated at runtime and can only record the current time of their generation.

>>no date types in sqlite
>use unix timestamps (integers)
kek

we've already established that isn't necessary

He should be storing iso datetime strings

Let me guess. You "need" more?

diferent use case scenario, also no one give a fk about this