It requires minimal javascript support-- just enough to build an img tag with the appropriate data url, and renders just as fast as any other tiny image. Upscaling blurs away the imperfections.
And I figured, yeah, that's still a lot of data, and it's massively misusing several different tools. Why not create something that is actually designed for the task?
This is really disingenuous-- a DBA should not be a gatekeeper of what gets put into a database. Storing 200 bytes of extra data per row costs you absolutely nothing. Even if you assume 100 million photos, that's 20GB of data. That's a little over $2 of EBS cost per month. Who cares.
To be fair, isn't it the DBA's job to gatekeep the database? The application programmers and business managers don't have the in-depth understanding to know how every individual change will effect the database. Of course they should follow best practices, but it's not really their job to know it inside and out - that's what the DBA does.
You don't know that 200 bytes per row would cost nothing - that's the DBA's job to understand it's cost. And we aren't talking about the amount of data, but without an in-depth understanding of what tables they were adding it to, how they're indexed, cached, etc, then you don't know the real cost. That 200 bytes might mean less can be stored in memory, if this is a frequently fetched table then that could be bad.
That's not to say the DBA made the right call, but that we don't have enough information to know if it was.
Gotta love organic db schemas with long history...
This is horrifying, but at least not as horrifying as the public sector database I once had to work with that predated proper support for foreign keys, so there was a relationship table that was about 4 columns wide and must have had more rows than the rest of the database combined.
Even the database they had moved this schema to struggled with that many join operations.
But parent is right that the choice of what shouldn't be coming from your DBA; they should be more interested in how.
That isn't the end of the conversation; if the response to "we shouldn't do Y" is "it'll be a pain if we can't do Y", then you can explore solution space together, where that solution space includes both trade-offs to support doing Y and alternatives to doing Y. Use experts for their expertise, rather than the equivalent of "I don't care, make it happen".
Or, in short: yes, of course the DBA doesn't unilaterally dictate the architecture, but maybe listen to their expertise anyway.
[edit: and that almost all network traffic is now L7 routed because of gatekeeping firewall administrators in the late 90's, so everything had to go over :80 or :443]
Seems kinda rude to ignore the motivations and incentives of the people who are responsible when problems happen.
Yes devs and infrastructure are often at odds professionally by design. Making it personal ignores the reason that different parts of the app have different owners that must agree to make changes.
“Those damn developers won’t just let me push my hotfix to master and make me have to do a code review when our severs are getting hammered.”
"Why are we creating new table and foreign key relationships for this single bit of data?"
"Oh, because we aren't allowed to add any columns to <the appropriate table>"
"Wait. None?"
"None."
(Only the last conversation I had of this sort involved MySQL, which was notoriously bad at adding columns to live tables)
The cost of 5 extra joins for all business activities is going to outweigh whatever you think you have going on with that original table.
I think in some ways the situation was improved by expanding developer responsibilities to include these tasks rather than having a dedicated role. When you have to deal with the consequences of your own decisions instead of someone else being responsible, some activities won't be done at all, while others will go more smoothly. Without the database being personified, it's more of a doing something for somebody (else) instead of doing it to somebody.
Don't think that's the correct adjective here.
That is not my experience at all. On images less than 100kb, webp adds an overhead, and doesn't reduce the file size at all. A fixed header is also harder to achieve.
That 607B of fixed header includes some compression settings that don't need to change between images:
- 132B of quantization tables, saying how much to divide every coefficient by-- for subtle details the difference between "128" and "129" doesn't matter, and you can just send "2 * 64".
- a 418B Huffman table, which stores the frequencies of different coefficient values after quantization-- small values are much more common than large ones, given the divisors. You can have smaller image data with properly tuned tables, but that only matters for large images. For 250B of image data, it's a waste.
- Miscellaneous other details that are fixed, like the file type magic headers, the color space information, and start/end markers.
You can dig in more by putting a thumbnail like https://i.imgur.com/M0EsJH1.jpg into this site: https://cyber.meme.tips/jpdump/