You quickly whip up a migration for your new silver-bullet table, carefully making note to use the GIN index so that you could later query by the contents of the JSON…
And since it sits on top of ActiveRecord::Store, it should function completely transparently. Thankfully, the good folks on The Internet have thought of a solution to that issue as well, and produced an activerecord-typedstore gem which will pull the data out from the JSON, cast it into the necessary types and save it into the model. One issue remains, however, and that is actually deserializing the data into our models. This just might be the silver bullet to keeping your architecture DRY and the future DBA happy, or at least not pulling his hair out. Not to mention that PostgreSQL, being the serious database that it is, actually saves data to the disk. However, you also remember that PostgreSQL came out with a JSONB field relatively recently, which lets you use PostgreSQL as a makeshift document storage database, while still being relatively performant and usable.
RAILS POSTGRES JSON QUERY FULL
The reactions were mostly mellow, due to the fact that you still needed to have separate fields on the actual table and Rails would merely hide them out of sight this would inevitably cause your schema to become bloated and full of useless, nullable fields. Many moons ago, you have read that Rails has a somewhat obscure feature called “Single Table Inheritance”, allowing you to dump several types into one table. You are pretty sure Martin Fowler said empty classes are bad at some point, but who’s keeping track, really? The Epiphany Something like this would be the apex of Good Design. If you were modelling this without any database concerns, you would obviously recognize that both Reminder and Alert could share the same superclass, like a Note. You also can’t add more types without updating the database for every type you add. Maybe ActiveRecord has transitioned into a full blown ActiveRDBMS and you can only ActiveQuery it over ten layers of ActiveAbstraction. Moreover, how are you going to query for both Reminders and Alerts together? You could work out something with UNIONs, but that is so cumbersome and SQL is so 1986, and you aren’t sure if Ruby on Rails even lets you use SQL these days. However, you’re obviously duplicating definitions of three fields. If you follow through with this structure, you will have a minimal and sufficiently normalized database, like they taught you at the aforementioned university. Immediatelly, your OO-senses start tingling. That student loan is practically repaying itself at this point. You then recall entity relationships charts from your brief tenure at a public university that left you jaded for life and figure that drawing up a relationship diagram is as good of a start as any.
You quickly resist the urge to just dump everything in MongoDB, call it “event sourcing” and leave the company at the first sign of issues, instead opting to think about all the types of data that the system should know about. The ConundrumĪs the requirements slowly start dripping in, you figure you might as well work on a proof-of-concept to pass some time. However, Bob knows that you definitely want to have more than one user, you definitely want to have a way to mark the reminders as completed, they will all definitely have a title and there will definitely be in-app purchases, though that last part is not really relevant to us now. Bob, your Product Owner, originally only wants two kinds of notes: reminders and alerts, but in his infinite enthusiasm as a new hire Bob can foresee many other types of reminders that the user will be able to create, it’s just that the ideas are pretty vague right now. You’ve been employed by an up-and-coming startup to provide a backend for their hip new productivity app, Notes McNotesface, which will easily let their valued customers add various types of notes to make them feel like they are getting something done. This post originally appeared on my Medium blog.
0 kommentar(er)
