This is the answer i was hoping for. Thank you.
On Tuesday, October 10, 2017 at 8:54:33 AM UTC+2, Marco Pivetta wrote:
>
> I talked about 100M+, at which point I'd question if operations should
> ever go through a serialisation layer (Doctrine) anyway.
>
> Basically: is an 8 times larger (than a
I talked about 100M+, at which point I'd question if operations should ever
go through a serialisation layer (Doctrine) anyway.
Basically: is an 8 times larger (than a smallint) column really the problem
here?
Even then you can replace UUID generator with a global identifier generator
producing
Although i get your point of view, and i appreciate your answer, i don't
like to design my database on the assumption that there will be 100 records
in it. If that would be the case, i wouldn't even bother asking for your
advice/opinion in the first place.
On Tuesday, October 10, 2017 at
Why is everyone stuck with this silly performance question?
Let's talk again when we have 100M+ records, shall we? Until then, it's 16b
vs 2b.
The fact that you are using PHP is your first performance/memory bottleneck.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On
I've recently stumbled on a Marco Pivetta's PHP Conf speech about Doctrine
Best Practices and Tricks,
and i really like solutions and the whole idea of immutability.
Even tho, if one wants to achieve Immutability, he cant use
auto-incremented integer strategy anymore, because it would break the
