Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am still fairly new to creating rails apps from scratch and would like to know the best way to set them up for efficient queries.
Consider this scenario. You are building a social site that shares books using mysql2 for a database. You start with two models; a user and an author. Both need name attributes; first_name, middle_name, last_name etc.
Would it be more efficient to create a name model where name would be it's own individual table?
Or add name attributes to the individual user and author where the attributes remain as columns?
First, you might consider implementing this using PostgreSQL - there are many, but performance is one of the reasons.
More, you have to think the system you build should be maintainable. Having a separate table for the name can be a very bad idea. Do you plan to add names for all the models you have in that one name table? Sounds weird. What problem do you think you could solve by doing that?
Instead, I think indexes can help you out (https://tomafro.net/2009/08/using-indexes-in-rails-index-your-associations) when it comes to retrieving associations.
And I cannot give you more advices on your data model. This depends on the requirements and future intentions. Are you going to query per model and then retrieve associations? Is there going to be sort of a tagging approach to handle synonyms?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am aware that this question is asked before and common solution would be like in this link. Separate tables and use join to get information
How to store multiple emails work, personal etc for one contact in MySQL
I just want ask is there any drawback if i saved comma separated emails, numbers, fax or address . This will also eliminate Joins hence better performance. Thanks in advance
With any database-driven application, it's helpful to ask: "What questions does my application need the database to answer?" In other words, what are the main use cases for querying?
The link you provide is basically an example of normalized relational database architecture. Normal forms are meant to minimize duplicate data and ensure data integrity. Within those "quality-control constraints," query-writing is supposed to be fairly patterned and predictable.
Will you need to know if a contact has duplicate email or phone numbers? If multiple contacts share the same email or contact? If phone1 is missing but phone2 is not missing? If all the phone numbers have international prefixes? Those are all questions that can be answered with a database query. And those queries would be much easier and much more straightforward to write with a normalized database (like the one in the link). With data in a single field of comma-separated values, the queries would be hard, impractical, ugly, or virtually impossible to manage.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
How to build a nice schema for activities in a database?
One activity can relate to one of 50 different entities.
For now i see only 3 solutions:
Table "activity" contains 50 columns with foreignkeys to the other entities.
This results in a very big table, which i do not like.
Each entity has its own "activity"-Table.
This solution results in nearly doubling the tables in my database, but its clearer. Still not the best solution.
Dirty one: "activity"-table contains one "entityType"-column with the entity-table-name and a other "entityId"-columns with the id to the entity.
But this solution break all foreign-keys and allows to store crap data in my activity table.
Perhaps somebody of you build a CRM and had to face with the same problem.
Does anyone have a better and clean solution?
Like i see, there is only a decission to make. First and second possibility are good because the keep the consistency of the db. In my case i decided to use 1. possibility.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a question about how big companies manage a database structure, let's say if i have an ecommerce app something like shopify which is the best approach you take:
a) When a new user creates an account a new database with his tables is created specifically for that user (i think if for some reason this database fail the other databases of other users remain working)?
b) When a new user creates an account Instead of create a new database, the app just create a new row in a table for his login and then all the products of all users are in the same table and only the user_id is the difference between one product of a store and another.
Thanks in advance.
Yeah, you should go for the second option (b), for alot of reasons:
1. Most of the data in your database shall be accessible for all users, so you don't want to have the same data stored in multiple places.
2. Sooner or later, you will come up with features where you want to share or link data between different users, etc.
3. Your first choice (a) would be extremely resource consuming compared to the second choice (b).
4. Well, the list can go on and on... :)
Obviously, the second choice - much more efficient and smarter.
Think about the number of the users, let's say 10k for example.
you realy don't want to handle this mass of tables!
I would go with Option B. This will reduce your work load and help in reporting needs down the road. Just make sure you use a robust database design to handle load when writing to database tables.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm worry about the performance when using relationship() in SqlAlchemy. For example, I have 2 tables: Users and BlogPosts, and the relationship between them is one-to-many. If I use relationship(), user.blogSpots will be a list of BlogPost, so I suppose a user (Alex) has 1 million BlogSpot, oh, user.blogSpots is very large because it contains 1 million items, right? If it's right, it must fetch 1 million result rows from database? I think in a real world application, the data are huge and maybe the performance will be slowdown.
So what is the benefit of relationship() in SqlAlchemy? Using a normal "sql query" with limit clause is better (memory + performance), isn't it?
The benefits of the relationship are actually pretty straightforward: list/add/remove/update related entities.
The case you describe, however, is one of the special cases where one should work with relationships in a non-default way. I suggest you read Working with Large Collections secion of Collection Configuration and Techniques in the documentation.
Applicable to your case would be usage of dynamic relationship, which returns only a pre-configured query, so you can further work on it as you wish:
apply filters
apply limits to select only top N ordered by field X, etc
Something like this would be an example of usage:
class Users(Base):
blogSpots = relationship("BlogPosts", lazy="dynamic")
...
user1 = session.query(Users).get(1)
assert user1
top10byDate = users1.blogSpots.order_by(desc(BlogPosts.POSTED_DATE))[:10]
taggedTech = users1.blogSpots.filter(BlogPosts.tags.any(Tag.name == 'tech')[:10]