I always wondered How can design database for blog platform like blogspot.
for example for posts what is good design for medium size blog platform:
put all posts from all blogs in one table and use something like blog_id column for them.
every time new blog request come create whole tables that needed in same database, and name tables like post_blogId (post_1, post_2).
create separate database for each blog
I think number two is better but question is a platform that has 500,000-1,000,000 blogs must have 500,000-1000,000 tables for posts and also for comments..!! does it efficient??
what about choice number 4??:
use solution 2 but for something like each 500(what this number should be??) blog create separate database.
I really have no idea which one would work efficient :(.
Related
I have a general architectural question concerning the design of part of a database. I would like to implement an archive for an educational entity and have a form field, where I can query the archive and get a certain subset of entries. Everything started with only an archive of articles and lectures. I treated both as similar and used one table named resources with columns for all the data I needed in both cases. This way I could write in my Rails app something like:
Resources.find(:all).where('title LIKE ?', "%#{params[:searchTitle]}%")
and get all the resources with a certain string in its title.
Now I would like to extend the archive to comprehend a wider set of resources containing documentation of educational or research activities. I will have items as well as what you could call collections and sub collections. Items would be things like sheets, texts, images, magazines, books, music, video, drawings, models, maps. Collections would be something like courses, lectures, exercises, projects, exhibitions. A course can have multiple exercises and lectures. An exercise can have multiple projects, etc. But there might be projects without an exercise or course. I might choose to add keywords to the resources to describe content.
A query should result in a view with all related entries of single items and collections in one list.
I would usually create a table for each resource in order to have as few repeating data as possible. But I usually have one table as entry point for my queries and would have now 14 resources tables + join tables + tables such as authors. How should I set up the structure of such a database and in case I will have to create single tables for each resource: How do I query 14 tables and display the result in one list.
Thank you in advance.
in your controller action method,
resources1 = Resource1.where("title LIKE ?", "%#{params[:searchTitle]}%")
resources2 = Resource2.where("title LIKE ?", "%#{params[:searchTitle]}%")
resources3 = Resource3.where("title LIKE ?", "%#{params[:searchTitle]}%")
#total_results = resources1 + resources2 + resources3
I know, there already is similar questions, but I can't find a good answer at my problem.
I'm developing a social network, I have all my users in a table, but each users must be able to save multiple post from the website.
My Question is:
How can I store all the saved post for each user without creating a new table for each users. I know this is bad to do this, so I'm looking for an alternative
If I understand you correctly, you just need a middle table (for example names user_post) that have 2 columns : user_id and post_id
this is a simple implementation of a many-to-many relationship
You only need a table to store all posts call it posts table with structure like this:
|post_id|user_id|title|content|etc..|
So you can do something to save posts and identify them by user_id.
It's called one-to-many relationship, you can search more about database relationships.
I am trying to learn magento framework. But it is hard to understand the database structure. So I am looking for a document that describe what each table exactly do and explain each column in that table. I have searched on google but all I found was magento database structure without any describes (table and column) Magento Database Diagram
ex:
the field converted_at in sales_flat_quote table. I have no idea what this field do.
What I looking for is like this topic excellencemagentoblog.com: Magento EAV Database Structure but it is only describe eav table
ps: so sorry because my bad english
Below link would solve all you queries related to Database Structure :
http://excellencemagentoblog.com/blog/2011/09/07/magento-eav-database-structure/
Below 2 links would show you the Database Diagram :
http://inchoo.net/wp-content/uploads/2010/09/MAGENTO_v1.3.2.4-Database_Diagram.pdf
Its better if you go through whole Magento Knowledge Base Documents available first and then go for understanding the Database.
EAV tables are used to give us the flexibility of adding unlimited Attributes for Products, Categories, Customers etc at any point of project even without bothering to update the database.
You need to understand Stores, Eav Attribute Set, Product Attributes, Website as all of this values are stored in Tables to differ the values.
I'm creating a small community using the Symfony2 Framework and backboneJS.
When I took a look at the database today I realized that it might be wrong to store all images using this schema.
ImageTable
Id
Title
Owner
Description
Url
So when a user logs in and wants to have a look at his own images, I just loop through all images where owner == currentuser.
Is this a bad practice?
The more owners I have the longer the query its going to take, right?
I'm asking since it might take a week to restructure the whole website database and I don't want to fix what might not be broken.
I know a solution might be to set a manytomany relationship between the current user table and an own image table, but is it worth the effort?
As far as I can see, this is as normalized as it gets for your scenario. A many to many relationship is not what you are looking for, since a user may have multiple images, but an image can't have multiple owners (or can they?).
So if the Owner is a foreign key for the table user you are good.
I'm not a professional, but I'm messing around with wordpress trying to customize it the way I want it to work...
I've a necessity to add additional data to single-posts, specifically a restaurant menu, each post will have unique menu displayed in sidebar.
Single post is a single row in wp_posts table.
I'm adding additional info using wp metabox functionality, which has its own table called wp_postmeta.
This table is different from wp_posts because it can contain many rows of meta information for a single post.
My questions:
Is this implementation slow?
Will it cause problems if db grows?
Why would wp guyz implement this in this way?
Would not it be wiser to have single meta column and multiple rows per post?
I see that you have "price_list_heading", "price_list_category","price_list_heading1", "price_list_category1","price_list_heading2", "price_list_category2","price_list_heading3" and "price_list_category3" I don't know why, but I think you shouldn't do that, you need to create a relational table with index (I don't know if Wordpress let you do that)
it'd will look like: this will depend of the cardinality of your APP
Let's say that 1 post meta can have multiple categories and multiple categories can be with one postmeta (cardinality N:M)
Now If one post can have multiple categories and one category can have only one post
Where wp_postmeta_copy1 is a FK from ws_postmeta table (id)
Please take a look to this documentation :
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
http://www.inf.unibz.it/~franconi/teaching/2000/ct481/er-modelling/
http://searchsqlserver.techtarget.com/definition/entity-relationship-model