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]
Related
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
So i have a website where users create their own 'shops' and then they can put items in the shops, so would it be practical to create a table for each user's shops or should I just add user IDs to posts?
You should add user ids to shops/posts. There are numerous reasons why you do not want to have separate tables for each user:
MySQL is designed to handle tables with lots of rows, not lots of tables with the same structure.
Structuring queries that goes across tables will require combining lots of different tables.
A small change to the data structure, such as adding a new column, becomes a nightmare.
Foreign key references to the shops becomes impossible.
If the data for a user doesn't fill a single data page, you end up wasting a lot of memory.
There are some reasons why splitting data into separate tables might be necessary. Here are some possible reasons:
Access is more easily managed at the table level than at the row level.
Replication of the data for each user might have different requirements.
An external entity requires that the data be in separate tables or databases.
However, the first set of reasons seems to weigh much more heavily to single table/entity structures. These more advanced concerns do not appear to be an issue.
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 6 years ago.
Improve this question
I have two tables in my db:
Marketers:
Id, Username, Password, Email
Stores:
Marketer Id, 1 Store, 2 Store, 3 Store, 4 Store, ...., 10 store
there is the names of 10 stores for every marketer in Stores table.
So there is a one to one relationship between these two tables. right?
I'm wondering if it would be better to just combine these two tables or not.
I wan't to send a lot of query for the second table (Stores tables). so I though this would be better if I separate these two cause I rarely need the information stored in 'Marketers table'.
From a good design perspective, you should keep these tables as separate.
for your current requirements,
if you do not need data from Marketers so often, why do you need to include that in Stores. you would just end up fetching extra data each time.
say if tomorrow if some new info and the mapping changes to one to many or vice versa, your current design will work perfectly fine.
and of course from future maintainence view, it is easier to update current design.
although, i would also, suggest you to add an independent primary to Stores table also.
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?
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 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 use symfony on my web page, I want to use both mongodb and mysql in my database model, and i don't know how to link between a table on my sql and a document on mongodb.
Example: PERSON -- relation 1--n -- ADDRESS, where PERSON is a table on my mysql database and ADDRESS is a document on mongodb.
Is it possible? How can I do it? Thank you.
Not possible if you want to have as strong a relation as e.g. foreign key constraints. The two databases will never have immediate knowledge of each other's data, transactions (!), scopes, etc. You can carefully write code that synchronizes the two. One approach I find easy and reliable: (for the reference, documents are data block of NoSQL [entities in NoSQL] while records are data items of SQL [entities in SQL])
All documents are children of one record (or not transaction-safe).
All transactions are controlled by SQL.
Locking a record for writing implies locking all child documents.
Updating a document requires the parent record to be locked.
One NoSQL transaction (if the feature is available) is nested right inside any SQL transacion.
DB cross-references are simple data; don't expect either the DB or Doctrine to handle them specially.
In this manner the two databases can be used in sync, relatively safely with transactions and locking.