I'm busy with a rails 4/postgres project that is structured in such a way that requires dozens of fields for a specific object, this being company. Each company would include fields for eg name, location, header_bg, logo, contact name, contact cell etc so the fields very well could grow in the future. What is the best way to structure this DB.
The way I see it I have 3 options:
1) company table with all these fields in the same table
pros: simple, data all in one place and easy to query
cons: table could get very messy and requires manually editing table structure every time a new field is required
~~~~~~
2) company table with an additional company_options table a foreign key company_id. This table will also hold multiple fields
pros and cons are same as above except this will be more neater structure. Crucial data such as company name will go in company table, other data like location, theme, header_bg etc would go in company_options
~~~~~~
3) company table and a company_meta table. This will follow the Wordpress structure of the post_meta table. So it would have the fields: company_id, meta_key, meta_value. each field would go in its own row
pros: flexible, able to dynamically add options/fields without editing table structure
cons: not a simplistic approach with same data in same columns. would need to custom build this functionality for inserting, updating, validation displaying of data. Unless Rails has such a gem which I can't find?
~~~~~~
Any suggestions or additional options would be appreciated. Are there any rules of thumb for determining the kind of structure needed? I started out with the 1st option out of a matter of simplicity but then started to build the 3rd and the amount of code just didn't seem right for what seems like such a common need.
Thanks!
Plan your database schema for the future:
Will a company be able to have several phones?
For repeating information, use a new table:
rails g model phone number:string type:string
rails g migration add_company_id_to_phones company:references
This way you can add several phones and navigate your database to get each phone.
Will your field only have one of a kind?
For example, you might only need one name field for each company. If this is the case, add it directly to the companies table:
rails g migration add_fields_to_companies name:string
Is your data completely optional? Is it unstructured?
Add a JSONB field to your table, assuming you are using Postgresql:
rails g migration add_details_to_companies details:jsonb
With JSONB data type you can use unstructured data like this:
Company.create({
name: "AwesomeCompanyCorp",
details: {
"main phone": "000-0000-0000",
"secondary phone": "000-0000-0000",
"support email": "support email",
"location": "Main Avenue 165",
"latitude": "22.330213123",
"longitude": "60.000012312"
}
})
With JSONB you are able to have unstructured data, but be able to query the field like this:
Company.where("details->>'main phone' = ?", "000-0000-0000")
With this on mind, choose the best approach that fits your case.
Related
I'm a learning developer building a Product & Inventory tracking platform for the company I work at and my Rails application has a Products table. Within the Products table are a bunch of basic entries, such as SKU, Description, UPC, Manufacturer, etc.
What I want to do is have an option within the Create page to insert custom parameters into something like a text_area to create Product specific entries, for example if I have only a small set of products that would benefit from a Voltage column and don't want to flood my migration with a bunch of lesser used options. What I'm picturing:
'Voltage|120 Volts'
'Housing Material|Steel'
'Duct Size|4"'
and then these could be their own rows in the Product's Show page.
Is anybody aware of a Gem or template that already accomplishes this, or would I need to dive in the deep end myself? I fear something like this is out of my skillset currently.
You can have one hstore column in the migration which will allow you to store multiple dynamic values in the single column as a hash.
You can read more about hstore from here.
I used hstore to store dynamic variants of product in the table.
I'm trying to make an online marketplace Rails App and I wanted to add a new column to my database conditional on another column.
I have a rails model "listings", which contains fields: "name, price, description, category." There are several categories: e.g., "Apartments, Books, Electronics,..." I want to add "Lat" and "Lon" geolocation columns only for Apartment listings. Would this be possible? How would I go about it?
I'm new to Ruby, so I apologize if this is a really easy question.
Thanks!
#Saraf answer nails it pretty much. Well, this is the case that you consider you have a SQL database. If you want to use a NoSQL database, such as MongoDB, you can store whatever you want inside collections (think about it as storing JSON objects).
Edit: clarification
You use SQL DB and you need to think about your relational schema and how you will handle different data (inheritance, for instance).
You use NoSQL DB and you can store "JSON objects" freely in your collections.
Since a model is a table, all the records will have the same attributes.
You can let them nil for other categories than apartments (and keep only one model), or you can create an herited model Apartments from Listings (http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html).
We haave Accounts, Deals, Contacts, Tasks and some other objects in the database. When a new organisation we want to set up some of these objects as "Demo Data" which they can view/edit and delete as they wish.
We also want to give the user the option to delete all demo data so we need to be able to quickly identify it.
Here are two possible ways of doing this:
Have a "IsDemoData" field on all the above objects : This would mean that the field would need to be added if new types of demo data become required. Also, it would increase database size as IsDemoData would be redundant for any record that is not demo data.
Have a DemoDataLookup table with TableName and ID. The ID here would not be a strong foreign key but a theoretical foreign key to a record in the table stated by table name.
Which of these is better and is there a better normalised solution.
As a DBA, I think I'd rather see demo data isolated in a schema named "demo".
This is simple with some SQL database management systems, not so simple with others. In PostgreSQL, for example, you can write all your SQL with unqualified names, and put the "demo" schema first in the schema search path. When your clients no longer want the demo data, just drop the demo schema.
I'm building a Ruby on Rails App for a business and will be utilizing an ActiveRecord database. My question really has to do with Database Architecture and really the best way I should organize all the different tables and models within my app. So the App I'm building is going to have a database of orders for an ECommerce Business that sells products through 2 different channels, a subscription service where they pick the products and sell it for a fixed monthly fee and a traditional ECommerce channel, where customers pay for their products directly. So essentially while all of these would be classified as the Order model, there are two types of Orders: Subscription Order and Regular Order.
So initially I thought I would classify all this activity in my Orders Table and include a field 'Type' that would indicate whether it is a subscription order or a regular order. My issue is that there are a bunch of fields that I would need that would be specific to each type. For instance, transaction_id, batch_id and sub_id are all fields that would only be present if that order type was a subscription, and conversely would be absent if the order type was regular.
My question is, would it be in my best interest to just create two separate tables, one for subscription orders and one for regular orders? Or is there a way that fields could only appear conditional on what the Type field is? I would hate to see so many Nil values, for instance, if the order type was a regular order.
Sorry this question isn't as technical as it is just pertaining to best practice and organization.
Thanks,
Sunny
What you've described is a pattern called Single Table Inheritance — aka, having one table store data for different types of objects with different behavior.
Generally, people will tell you not to do it, since it leads to a lot of empty fields in your database which will hurt performance long term. It also just looks gross.
You should probably instead store the data in separate tables. If you want to get fancy, you can try to implement Class Table Inheritance, in which there are actually separate but connected table for each of the child classes. This isn't supported natively by ActiveRecord. This gem and this gem might be able to help you, but I've never used either, so I can't give you a firm recommendation.
I would keep all of my orders in one table. You could create a second table for "subscription order information" that would only contain the columns transaction_id, batch_id and sub_id as well as a primary key to link it back to the main orders table. You would still want to include an order type column in the main database though to make it a little easier when debugging.
Assuming you're using Postgres, I might lean towards an Hstore for that.
Some reading:
http://www.devmynd.com/blog/2013-3-single-table-inheritance-hstore-lovely-combination
https://github.com/devmynd/hstore_accessor
Make an integer column called order_type.
In the model do:
SUBSCRIPTION = 0
ONLINE = 1
...
It'll query better than strings and whenever you want to call one you do Order:SUBSCRIPTION.
Make two+ other tables with a foreign key equal to whatever the ID of the corresponding row in orders.
Now you can keep all shared data in the orders table, for easy querying, and all unique data in the other tables so you don't have bloated models.
How do I save multiple values in a single cell record in Ruby on Rails applications?
If I have a table named Exp with columns named: Education, Experience, and Skill, what is the best practice if I want users to store multiple values such as: education institutions or skills in a single row?
I'd like to have users use multiple text fields, but should go into same cell record.
For instance if user has multiple skills, those skills should be in one cell? Would this be best or would it be better if I created a new table for just skills?
Please advise,
Thanks
I would not recommend storing multiple values in the same database column. It would make querying very difficult. For example, if you wanted to look for all the users with a particular skill set, the query would clumsy both on readability and performance.
However, there are still certain cases where it makes sense.
When you want to allow for variable list of data points
You are not going to query the data based on one of the values in the list
ActiveRecord has built-in support for this. You can store Hash or Array in a database column.
Just mark the columns as Text
rails g model Exp experience:text education:text skill:text
Next, serialize the columns in your Model code
class Exp < ActiveRecord::Base
serialize :experience, :education, :skill
# other model code
end
Now, you can just save the Hash or Array in the database field!
Exp.new(:skill => ['Cooking', 'Singing', 'Dancing'])
You can do it using a serialized list in a single column (comma-separated), but a really bad idea, read these answers for reasoning:
Is storing a delimited list in a database column really that bad?
How to store a list in a column of a database table
I suggest changing your schema to have a one to many relationship between users and skills.
Rails 4 and PostgreSQL comes with hstore support out of the box, more info here In rails 3 you can use gem to enable it.
It depends on what kind of functionality you want. If you want to bind the Exp model attributes with a form (for new and update operations) and put some validations on them, it is always better to keep it in a separate table. On the other hand, if these are just attributes, which you just need in database keep them in a single column. There is way by which you can keep the serialized object like arrays and hashes in database columns. Make them a array/hash as per your need and save it like this.
http://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/Serialization/ClassMethods.html#method-i-serialize
Serialized attributes, automatically deserializes when they are pulled out of tables and serialized automatically when saved.