I have a Rails app that displays transportation prices of companies (think e.g. momondo.com).
Those companies are 'created' using the same data model for all of them. Every company has its unique way to calculate a price.
I have to implement different algorithms for every single one. In some cases an 'algorithm' could just be a lookup in a table, in other cases it's a math formula.
So, what kind of data model is the most appropriate here?
Thanks in advance
Whether it's a SQL query or a math formula, it would still be ruby code. So I'd suggest putting them in classes (you can afterwards decide if you declare these classes dynamically or not) with, in combination, a strategy pattern
I have an application that sounds a lot like yours (different domain). I ended up creating a Rule class that has a rule attribute that is a jsonb type. Then I created a rules engine (none of the Ruby rules engines fit my needs). So, I just select the appropriate rule (in my case, using a combination of organization and name since my organizations can have multiple rules) and then pass this to my rules engine for evaluation.
Currently, in my application, rules are defined in YAML files, but I'll be creating a front end so that organizations can use the UI to define their various rules.
I realize that's very high level, but hopefully it gives you a directional sense of how another person approached the problem.
Related
This is a design question. I hope that is acceptable here.
Back in the days of yore, I worked on an accounting system that used flat files to store records in a proprietary format. The transaction 'table' stored multiple types of transactions in the format of a fixed header (which held the transaction type amongst other things) and a detail record that varied according to the transaction type.
We did this in C using structs and unions to manage the records.
Once again I find myself working on a finance system, only this time I'm doing it in Rails with PostgreSQL as the target database.
I'm currently considering the design of the transaction system in this new project and I'm wondering how to do this in the best, Rails way.
Do I have multiple tables, one for each transaction type: journals, sales, purchases, etc? (Does this violate DRY?)
Or, do I have a single transaction table that represents the header, and multiple tables for the detail of each type?
If I do it this way, how do associations work? Can an association use a single id to connection to multiple tables?
Or, do I have a single, un-normalized record with every possible field for the complete range of transaction types?
Or... is it possible to overload a table record in the way I did this so many years ago?
(Not really keen to do it this way though.)
Any ideas you have on this will be appreciated.
Option 1 sounds like you'd need a polymorphic association, which is supported by Rails out of the box. Although it works the other way around normally - The usual use-case is along the lines of a comment object that can belong to multiple content types. There's a gist here that may or may not help: gist.github.com/runemadsen/1242485
Although the gist uses a join table on which you can add common fields, which starts to sound like Multiple Table Inheritance, your second choice. This is a good solution. You'll need a gem to make it work with Rails though. Try this one:
github.com/hzamani/active_record-acts_as
Option 3 sounds like single table inheritance which is generally a bad move.
I'm not sure how 4 differs from 2.
I would err on the side of 2: Multiple Table Inheritance. Granted, if a polymorphic association works for you it's nice to be just using Rails native features, but I think you'd find it would get more and more annoying to deal with over time. Simple things like counting all transactions or getting all transactions within a date range would become arduous and fragile. MTI is a pattern created exactly for this kind of situation.
I'm working on a Ruby on Rails project. The project has a main database table, called 'Post'.
This table is used for storing questions, answers, comments and announcements as different post types. Currently we use only one model to access the data. But while working on the systems it feels cluttered. Because every post type has some differences.
What is a best practice:
Split the post resource into different resources, but using only the one Post table for data access?
Split the database table into comments, questions, answers and announcements tables; and use resources for each table (model+controller+views)?
Short answer: it depends.
What you're doing now is pretty close to Single Table Inheritance (STI), though it sounds like you're using a single Post class which contains all your different behaviors. STI is a valid approach to storing your model data, but like everything, it has advantages and disadvantages.
My recommendation would be to use separate classes to encapsulate the behavior of separate domain models. This is the fundamental paradigm in OOP, so I would say it's probably a best practice.
Assuming you split your behavior across classes, the question of whether you use a single table to store them or multiple tables really depends on the complexity of your queries and how many common fields there are across your models. If they share a lot of common fields, STI may work nicely. If not, you're probably not going to enjoy the overhead of all the extra reads/writes you'll pay. But all that is really secondary and can be figured out as your app grows and you learn more about the usage patterns.
Try it using STI and see how it goes. Splitting things up into multiple tables is easier than the opposite, so a migration path is not necessarily too hard.
I think the choise should be based on every certain situation. Just enumerate advantages and disadvantages of each option for you. Points to investigate and make decision could be like: number of differences between each type of entities, the way to access entities, frequency of usage of each type of entities, maintability of code, forecast of changes in the future, and many others.
If I have two tables in a DB User and Userinfo (split for normalisation purposes) I generate the two models User, UserInfo and use them as normal via relationships.
Later on I have section of my application that reads and writes to both, however, there is a fair amount of business logic on creating entries for example looking up other tables for conditional rules, string building etc.
Would it make sense to make a third model (a non-database-backed model) to handle all this and to create/save via the other two models? or should I keep this in the controller?
Another example could be importing a CSV file where all the data is split between different tables, separate models as used by the rest of the application. Could I use a model defining each row that handles saving the imported data via the other models. Or again should this be in the controller?
I am interested in the best practices when developing large rails applications.
Sounds like you're normalizing (minimizing redundancy) rather than de-normalizing.
I don't know your application, so please take this as something to consider rather than a recommended best practice: what I typically like do in a situation like this is hide the Userinfo behind the User, so that the User is the only part of the application that even knows there is a Userinfo. This keeps things simple and consistent and DRY across the other clients of the code (controllers, other models, and you when you interact with it in the console).
Introducing a third model might serve the same purpose, but it's also adding conceptual weight to the application.
The answer depends on why you split the user data into two tables in the first place - what problem was it supposed to solve. Figure that out and try to apply the same logic to the models.
In any case, I agree that it makes sense to create a third model that encapsulates the complexity of working with the other two. This lets you present a simpler interface to other layers of the application (controllers, views). However, you'll have to watch carefully how far you're going with this. If you find yourself re-implementing most of ActiveRecord::Base by delegating calls to your encapsulated components, then it may be time to reconsider.
BTW, what you did isn't de-normalization. De-normalization in the context of a relational database means creating redundancy (check out the Wikipedia article on normalization, de-normalization is the opposite). This is usually done in order to improve performance by reducing the amount of joins required.
I have an application which will require a "dynamic business rules" engine. Some of the business rules changes very frequently. Some of then applies for a limited set of business accounts. For example: my customer have a process where they qualify stores, based on their size, number of the sales person, number of products, location, etc. But he manages different account, and each account give different "weights" to each attribute.
How do I implement this engine using Ruby? I know Java has drools, but I find drools annoying and complex. And I prefer not having to use JRuby...
Regards,
Rubem
If you're sure a rule engine is what you need, you will need to find one you can use in Ruby. A quick Google search brought up Rools (http://rools.rubyforge.org/) and Ruby Rules (http://xircles.codehaus.org/projects/ruby-rules). I'm not sure of the status of either project though. Using JRuby with Drools might be your best bet but then again, I'm a Java developer and a big Drools advocate. :)
Without knowing all the details, it's a little hard to say how that should be implemented. It also depends on how you want the rules to be updated. One approach is to write a collection of rules similar to this: "if a store exists with more than 50 sales people and the store hasn't had its weight updated to reflect that, then update the store's weight." However, in some way you could compare that to hardcoding.
A better approach might be to create Weight objects with criteria that need to be met for the weight to apply. Then you could write one rule that matches on both Weights and Stores: "if a Store exists that matches a Weight's criteria and the Store doesn't already have that Weight assigned to it, then add the Weigh to the Store." Then the business folks could just create and update Weights, possibly in a web front-ended database, instead of maintaining rules.
Would any experienced Erlang programmers out there ever recommend association lists over records?
One case might be where two (or more) nodes on different machines are exchanging messages. We want to be able to upgrade the software on each machine independently. Some upgrades may involve adding a field to one (or more) of the messages being sent. It seems like using a record as the message would mean you'd always have to do the upgrade on both machines in lock step so that the extra field didn't cause the receiver to ignore the record. Whereas if you used something like an association list (which still has a "record-like" API), the not-yet-upgraded receiver would still receive the message successfully and just ignore the new field. I realize this isn't always the desired behavior, but often it is. Also, assume the messages are fairly small so the lookup time doesn't matter.
Assuming the above makes some sense, I have the following additional questions:
Is there a standard (or widely used) library for alists? Some trivial googling didn't turn up anything.
Are there other cases where you would use an association list (or something like it)?
You have basically three choices:
Use Records
Use Association Lists (proplists)
Use Combination
I use records where the likelihood of changing it is very low. That way I get the pattern matching and speed up that I want.
I use proplists where I need hashtable like functionality. I get flexibility at the expense of pattern matching and speed.
And sometimes I use both. A record with one field that is a proplist. That way I can pattern match on a portion of it and yet have flexibility where I need it.
All three choices have different trade-offs so you basically just have to evaluate your particular needs and make a choice. It may take some prototyping and playing around to figure out which trade-offs make sense and which features you absolutely must have.
For small amount of keys you can use lists aka proplists for bigger you should use dict. In both cases biggest disadvantage is that you can't use pattern match in way as used for records. There is also speed penalty but it is in most cases irrelevant.
Note that lists:keysearch/3 is pretty much "assq".