How can I structure a Rails application for a restaurant marketplace? I’m considering Eatery, Offering, and Cuisine models with support for dynamic images and detailed descriptions. See sample code:
class Eatery < ApplicationRecord
has_many :offerings
end
class Offering < ApplicationRecord
belongs_to :eatery
has_many :cuisines
end
class Cuisine < ApplicationRecord
belongs_to :offering
belongs_to :eatery
end
Hey Leo_Speedster, love to see this kind of project taking shape! I’m trying to wrap my head around your data relationships – it seems you’re carefully linking eateries, offerings, and cuisines but I’m curious if you thought about using a more flexible approach for the images and maybe even the cuisines? For example, perhaps a polymorphic association for images could come in handy, in case you want to attach them not only to eateries but maybe even to offerings or user reviews down the line. Also, how are you thinking about handling the dynamic image scaling or caching? I wonder if integrating something like Active Storage or even a third-party service might give you that extra edge. It’d be cool to learn what your thoughts are about device scalability as you add more detailed descriptions, maybe even menu items or user feedback. What’s your take on evolving the architecture as more features come into play? Looking forward to hearing more about your thought process!
The structure you proposed is solid, though your use of associations might soon become unwieldy as functionality expands. In my experience, keeping the relationships loosely coupled by employing join tables or even dedicated polymorphic associations for elements like images can offer more flexibility over time. I’ve worked on similar projects where detailed images, user reviews, and menu updates required adaptable database designs. A shift toward compartmentalized models improved overall maintainability and performance when scaling up the application.