I have this page table structure to store all the website page information,
page_id
page_url
page_title
page_subtitle
page_description
page_introduction
page_content_1
page_content_2
page_content_3
page_content_4
...
You can see that I have page_content_1 to page_content_4, instead of just page_content. The reason why I do this because I might want to store different types of page content for each page.
But I doubt whether this is a good practice or not? What if other developer comes to further develop on this page table, would you find this structure redundant?
I am thinking maybe I should create another table to store additional page content like this below?
table page_additional_content,
content_id
content_additional_1
content_additional_2
content_additional_3
content_additional_4
page_id
Is this better?
Or there is better standard idea that I should look into?
Building on Quentin's answer, if you want to be able to reuse content across pages (such as headers or footers), you could create a table structure like:
page_content:
content_id (primary key)
actual_content (actual content of the page)
page_structure:
page_id (foreign key of the page)
content_id (foreign key of the content)
order_in_page (order of the content in the page)
You content can grow to as many sections as you want without adding additional tables (just add a new row in page_structure and increment the order_in_page counter).
When you start having columns with the same name, but with a numerical suffix then you should usually start thinking "New table + foreign key".
You would probably be better off with something along the lines of a content table structured like:
document_id | page | content
1 | 1 | foo, bar, baz
Related
For a project I am making I need the possibility (like stackoverflow does) to save all the previous edit (revisions) for posts.
Consider I can have some 1 to N association with the post (for example 1 post with 5 images associated).
How would you suggest me to design the database for this?
Of course the ID of the post should stay the same to don't broke URLs:
site/post/123 (whenever revisions it is)
Each revisions to posts should be manually approved so you can't show directly the last revisions inserted. How would you suggest me to design the db?
I have tought
Table: Post
postID | reviewID | isApproved | authorID | text
And the image table (for example image, but it could be everything)
Secondary Table: Image
imageID | postID | reviewID | imagedata
Actually, I would split the post table in two, with the approved revisions in one, and the latest (not approved) revision in another. The rational is that any non approved revision which is not the latest would be supersceded by the next one (unless you really want to keep track of all the intermediate modifications, approved or not).
Table: OldPost
postID | reviewID | authorID | text
Table: PendingPost
postID | authorID | text
In that layout, whenever a new revision has been approved, it must be moved to the approved ones, but you don't have to filter them out when displaying the whole history, and conversely, you wont have to filter the approved revisions in the approval part of your site.
You could even refine the layout with yet another dedicated table for the latest approved revision (so three tables for the post in total, not counting attachements). This partitioning would improve the overall performance of your site for the most common queries, at the cost of more complex queries when you need all the data (less frequent operations).
Table: CurrentPost
postID | authorID | text
As you can see, this table structure is the same as the one for pending posts, so the updates would be trivial.
moving a revision to the old post table requires to find out the revision count, but you would have to do that operation anyway with a more classic db layout.
Regarding the attachment table, the layout seems to work.
Separate all aspects of a post between global information and versionable information. In other words, what things can be changed in a revision and what are always going to apply to any revision. These are going to be the fields in your two tables, one for your posts, and one for the revisions. You will also need a row to specify what post the revision is for as well as whether the revision is approved, and on the posts table, you need a row to specify what the current revision in.
I have a news system I'm designing, and it seemed straight-forward at first, but as I've pushed forward with my planned schema I've hit problems... Clearly I haven't thought it through. Can anyone help?
The system requires that the latest 20 news articles be grabbed from the database. It's blog-like in this way. Each article can have sub-articles (usually around 3) that can be accessed from the parent article. The sub-articles are only ever visible when the parent article is visible -- they're not used elsewhere.
The client needs to be able to hide/display news articles (easy), but also change their order, if they desire (harder).
I initially stored the sub-articles in a separate table, but then I realised that the fields were essentially the same: Headline, Copy, Image. So why not just put them all in one big table?
Now I've hit other problems around the ordering. It's Friday evening and my head hurts!
Can anyone offer advice?
Thanks.
Update: People have asked to see my "existing" schema:
articleID *
headline
copy
imageURL
visible
pageOrder
subArticleID *
articleID
headline
copy
imageURL
visible
pageNumber
pageOrder
Will this work? How would I go about letting users change the order? It seemed the wrong way to do it, to me, so I threw this out.
I initially stored the sub-articles in a separate table, but then I realised that the fields were essentially the same: Headline, Copy, Image. So why not just put them all in one big table?
Because referential integrities are not the same.
That is, of course, if you want to restrict the tree to exactly 2 levels. If you want more general data model (even if that means later restricting it at the application level), then go ahead and make a general tree.
This would probably look something like this:
Note how both PARENT_ARTICLE_ID and ORDER are NULL-able (so you can represent a root) and how both comprise the UNIQUE constraint denoted by U1 in the diagram above (so no two articles can be ambiguously ordered under the same parent).
Based on what you've described. I would use two tables. The first table would hold all the articles and sub-articles. The second would tie the articles to their sub-articles.
The first table (call it articles) might have these columns:
+-----------+----------+------+----------+---------+------------+-----------+
| articleID | headline | copy | imageURL | visible | pageNumber | pageOrder |
+-----------+----------+------+----------+---------+------------+-----------+
The second table (call it articleRelationships) might have these columns:
+-----------------+----------------+
| parentArticleID | childArticleID |
+-----------------+----------------+
Not sure if you already accomplish this with the pageNumber column, but if not, you could add a column for something like articleLevel and give it something like a 1 for main articles, 2 for sub-articles of the main one, 3 for sub-articles of a level 2 article, etc. So that way, when selecting the latest 20 articles to be grabbed, you just select from the table where articleLevel = 1.
I'm thinking it would probably also be useful to store a date/time with each article so that you can order by that. As far as any other ordering goes, you'll have to clarify more on that for me to be more help there.
To display them for the user, I would use AJAX. I would first display the latest 20 main articles on the screen, then when the user chooses to view the sub-articles for a particular article, use AJAX to call the database and do a query like this:
SELECT a.articleID, a.headline
FROM articles a
INNER JOIN articleRelationships ar ON a.articleID = ar.childArticleID
WHERE ar.parentArticleID = ? /* ? is the articleID that the user clicked */
ORDER BY articleID
The client needs to be able to hide/display news articles (easy), but
also change their order, if they desire (harder).
On this particular point, you'll need to store client-specific ordering in a table. Exactly how you do this will depend, in part, on how you choose to deal with articles and subarticles. Something along these lines will work for articles.
client_id article_id article_order
--
1 1067 1
1 2340 2
1 87 3
...
You'll probably need to make some adjustments to the table and column names.
create table client_article_order (
client_id integer not null,
article_id integer not null,
article_order integer not null,
primary key (client_id, article_id),
foreign key (client_id) references clients (client_id) on delete cascade,
foreign key (article_id) references articles (article_id) on delete cascade
) engine = innodb;
Although I made article_order an integer, you can make a good case for using other data types instead. You could use float, double, or even varchar(n). Reordering can be troublesome.
If you don't need the client id, you can store the article ordering in the article's table.
But this is sounding more and more like the kind of thing Drupal and Wordpress do right out of the box. Is there a compelling reason to reinvent this wheel?
Create a new field in news(article) table "parent" which will contain news id of parent article. This new field will be used as a connection between articles and sub articles.
As SlideID "owns" SubSlideID, I would use a composite primary key for the second table.
PrimaryKey: slideID, subSlideID
Other index: slideID, pageNumber, pageOrder (Or however they get displayed)
One blog post I prefer to point out about this is http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx as it explains why very nicely.
If you're replying on Auto_Increment, that can be handled too (with MyISAM tables), you can still set subSlideID to auto_increment.
If you're likely to go to a third level then merge - follow Branko above. But it does start to get very complicated, so keep separate for 2 layers only.
I am trying to figure out the best way to have a page dynamically know which data to output.
I have a index.php that I want to be able to pass some $_GET variables into it and then based on that know what to display. Aside from the content being different the type of the content is also different I have products and other types of pages like blog posts etc. The products are stored in different tables then the other pages. and also have a slightly different table structure as well.
currently I have the following tables.
Subjects, Pages and Categories.
Table = Subjects
id | menu_name | menu_number | category | menu_position | active
Table = Pages
id | subject_id | category_id | page_name
Table = Categories
id | category
These are the main tables that outline the main structure of the site. I then have secondary tables that contain the actual data for the pages.
posts, post_details, post_pypes and
products, product_details, product_types and product_specs.
What I want to active is that a variable will be send along in the query string and based on this the application will know what information to display .
My question is how can I make a table that will catalog all entries (posts and products) with a unique id and that will be the only variable needed to for my application to determine how to proceed. i.e. query the table int he database that is holding that unique id and tell the application its a "product" and the product id is X and to continue querying the needed tables for the info.
Thanks in advance.
I highly recommend looking into a secure, structured environment like CodeIgniter to accomplish whatever it is you are trying to describe above. The scope of that question is really broad which likely indicates that you would profit from a prebuilt framework of some kind.
I have 3 types of content: blogs, press releases, and reminders. All of them have a body and entered by fields. The blogs and press releases have a title field, which the reminder lacks, and the reminders has an hour field, which blogs and press releases lack. This is what it looks like in tabular format so it's easy for you to see...
blog press release reminder
---------------------------------------------------
entered by field yes yes yes
body field yes yes yes
title field yes yes --
time field -- -- yes
I'm creating a main table called content that links to the specialized tables blogs press releases reminders. I thought of 2 structures
First structure... This is how the content management system I use does it, but I don't want to follow in their steps blindly because my needs are not the same. Put ALL shared fields in the main content table. So the content table will not only have type and type id to link to the specialized tables, the content table will also have the common fields like body and entered by. The other 3 tables only have their unique fields.
content table B=blogs table PR=press releases table R=reminders table
------------------------------------------------------------------------------
id id id id
type=B/PR/R title title hour
type id
body
entered by
Second structure. content table only has the type and type id necessary to link to the other 3 tables, This means that the common fields get repeated in the 3 tables.
content table B=blogs table PR=press releases table R=reminders table
------------------------------------------------------------------------------
id id id id
type=B/PR/R entered by entered by entered by
type id body body body
title title hour
Which should I go with? I thought the first structure is better because I can search all content whether it's a blog or press release or reminder for a specific word. I still have to look in the other tables if I want to search the title which is available only to blogs and press releases, but...
So which structure is better, and why you think so? I'm also open to other ideas or improvements that are different from these 2.
The first structure is a classic super type-subtype approach, and recommended. I would just suggest naming primary keys with full table-name-id like ContentID to avoid possible confusion.
The first one is the better construct, it allows for a content to have a specific set of required or common data in the content table and then specialized data in the child tables. This also allows you to add more types in the future with other requirements that still reuse the common elements in content but retain any unique data.
One other key question is if that data is required, for example do all reminders require an hour and do all blogs/press release require a title. If they are required then you ensure that those child tables will always be populated. If they are not then perhaps you should look at flattening the structure (yes Virginia you should sometimes denormalize).
So instead your content table simply becomes (nn = not null, n = nullable)
id (nn) ,type id (nn), type (nn), body (nn), entered by (nn), title (n), hour (n). The main reason I usually find for doing this is that if the different data entities you are creating are so similar that over time it is possible they will merge. For example reminders at this time do not require a title, but in the future the might.
I would sooner go without any sort of "type" field, instead making four tables: content, blogs, pressreleases and reminders. Content has the common fields enteredby, body, and title. For each of blogs, pressreleases and reminders, they have an id that is a primary key and also a foreign key to a content id. This makes a 1:1 "is-a" relationship. reminder can have the additional time field. To determine what type of entry a content row is, do a join select.
This may not be the best in terms of performance but it's better normalized.
I think you should think about the common fields.
Do they really need to match?
If they need to match, it's easier to just put it in a single table.
What is the best way to count page views for dynamic pages like the url example below? I'm using PHP and MySQL. A brief explanation would help. Thanks!
http://www.example.com/posts/post.php?id=3
Usually the table structure looks like this:
table pages:
id | name | ...
==========================
1 Some Page
2 Some Other Page
table pages_views:
page_id | views
================
1 1234
2 80
where pages_views has a unique index on page_id
The MySQL statement to increment the views then looks as follows:
INSERT INTO `pages_views` SET views=1 WHERE page_id=?
ON DUPLICATE KEY UPDATE views=views+1 ;
Since pages_views.page_id is unique, the row for the page will get created if it doesn't exist; if it exists (that's the "duplicate key" clause), the counter will be incremented.
I chose two separate tables here, as CMS pages usually aren't updated too often (and therefore, their load is mostly reads), whereas page views are read and updated, well, with each page view.
This is my code and it's working properly when I open the page or When I refresh the page, page views is incrementing by 1. If the page_id doesn't exist it will insert a record with views = 1, if page_id exists it will increment the views
`INSERT INTO pages_views ( pages_id, views) VALUES ( $page_id, 1) ON DUPLICATE KEY UPDATE views=views+1`
With PDO you will have something like this
$sql = "INSERT INTO pages_views ( pages_id, views) VALUES ( :pageId, 1) ON DUPLICATE KEY UPDATE views=views+1";
$q = $conn->prepare($sql);
$q->execute(array(':pageId'=>$pageId));
Well, you can simply add a field pageviews to your pages table and do UPDATE pageviews = pageviews +1 WHERE id = 1 query on each page load
For the sake of viewing statistics by day/week/month/year, I have made two tables. The first archives all visits to the site with my page and id saved on the same row. The second table records tallys, such as Piskvor describes.
The benefit is that I can view stats for any page and ID I want over time (but that'll be a lot of rows over time...) or I can simply view total pageviews. For the visitors of my site, I serve information from this second table, but my admin panel makes full use of the first table.
statsEach
- statID
- page (example: page 100 is index.php, or 210 is news.php)
- id (example: 1 is news story 1, 2 is news story 2,...)
- date
- time
- user
and
statsTotal
- statTotalID
- page
- id
- total
I don't know what you need/want to do, or even if my table structure is best, but this works for me.
Just increase an integer on the post you currently serve.
A simple example can be found at http://www.configure-all.com/page_view_counter.php