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.
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 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 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]
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 5 years ago.
Improve this question
I have a table called enterprise in my database. If the enterprise expresses its demand to my company, the enterprise will become our prospection. And after, if the enterprise accept my company's proposal, we will sign the contract, and enterprise becomes out client.
Now, I have created 3 tables which are enterprise, prospection, client.
So, how should I design the database?
One approach would be to have a table Companies, and the three tables you already have. All three tables have field CompanyId that has a foreign key constratint linkining it to the companies table. This design has the advantage that you have to keep the company information in one place and there is no duplication.
Another way would be to have a field in the companies table, that marks them as an enterprise, prospect, or client.
Which design you should choose largely depends on information for the different classes. If you thinking along inheritance (i.e. a client is a prospect is a enterprise) than the company table suffices. However, if ther is a large amount of information and the information is different for each of the three classes than the first approach would be better.
You should, however, always try to keep the information in one place, i.e. in one field/table (= fully normalized). In some cases you can deviate from this principle for performance reasons, but keep in mind that this also means a higher maintenance overhead - you have to update n tables when a value changes.