separate image models for each parent model; same model for images and video ... good ideas ?

[fugee ohu]

if i have a lot of different models that can have many images is it better to have separate image models for each of them to make things easier for my server in high traffic conditions or let them all use the same image model? What about using the same model for images and video, let's say the vp model (video,photo) Are these good ideas? I'm preparing my models for bootstrap-image-gallery an extension to bluimp-image-gallery so i guess just consider i'm preparing my models for bluimp ~ thanks

[Colin Law]

On 18 January 2016 at 05:49, fugee ohu <fuge...@gmail.com> wrote:
> if i have a lot of different models that can have many images is it better
> to have separate image models for each of them to make things easier for my
> server in high traffic conditions or let them all use the same image model?

Can you explain why you think that it will make life easier for your
server if you have separate models?

Whatever the answer to the above, it is almost almost a mistake during
initial development to make your code more complex in order make it
more efficient. This is known as premature optimisation. Decades of
working in s/w design have taught me that the bottlenecks in code are
very rarely in the bits of code you expect. Design your system using
the KISS technique and make sure you have full automated test coverage
so that when you refactor the code you can be sure it is still
working. If you eventually get the the point where throughput is an
issue then that is the time to work out where the bottlenecks are and
solve those problems.

> What about using the same model for images and video, let's say the vp model
> (video,photo) Are these good ideas? I'm preparing my models for
> bootstrap-image-gallery an extension to bluimp-image-gallery so i guess just
> consider i'm preparing my models for bluimp ~ thanks

As I said, use the KISS technique. So use the simplest design that
will solve the problem. The simplest design will take less time to
develop and will have less bugs (as there is less code and it is
simpler).


Colin

[Colin Law]

A couple of caveats to my previous post:

If you find yourself writing the same code in two (or more) models
then there is almost certainly something wrong with the underlying
design.

If you find that two models contain fields of the same name where the
contents have the same purpose then again there may be something
wrong. Possibly the two models should be combined in some way, or the
common data moved out to a third table.

It is almost always bad to store data in one field that can be
calculated from other data in the same or other models. Instead of
the field provide a method that calculates the value on the fly.
There are times when this rule needs to be broken for efficiency
reasons but this decision should not be made at initial coding stage.
If it eventually proves that it is necessary then convert the method
to a field when it can be shown that it is really necessary.

Colin