frasmage
commented
5 months ago Those are just different designs optimizing for different things. This package aims for maximum flexibility. It records metadata about each variant as a full fledged media record. This allows either using the wordpress-like approach or always linking the original and letting the use case determine the desired variant (e.g. use the thumbnail here), as well as attaching specific variants directly to the mediable records (e.g. this article should use the sepia variant). This approach also allows for querying available variants directly from SQL, without needing to touch the file system (potentially more expensive with things like S3). Though the intervention/image integration only supports manipulating images, the variant system is designed to be able to link media of any type, e.g. a scientific study PDF linking to its summary PDF.
Though we try to be efficient, the disk limitations of your database are not a direct consideration of the package. It is up to you, the integrator of the package, to size your database AND filesystem infrastructure according to the needs of your application. The size of the files themselves is just as much of a scaling consideration (and likely much larger than a row in a database)
If you are creating so many variants that you are exceeding your available disk limits, I would recommend scaling up your infrastructure and/or sharding your database.
ehsan-soleimanian
I think we should not store variant in database in order to avoiding database overflowing . If we take a look at Wordpress database structure for image variants we see they access vairant by its name or its ratio statically and they are not stored in database.