I want to organize articles written on my website. Currently, I have an author submit their work to me (via email) and I copy/paste their article into a .php file and upload their file with FTP. At the same time I need to update the links for the navigation menu based on the new article.
I've been reading that I can put everything into a mysql database.
Right now, I have 2 Columns (a music column and a college life column) - each column will have articles updated every two weeks by a different author. How do I organize my database
What I was thinking...(after doing some reading)
Table Column:
Column_id
Name
Description
Create_date
Table Column_authors:
column_id
author_id
Table Articles:
Article_id
column_id
Title
Description/Summary
Body
create_date
Table Articles_authors:
article_id
author_id
Table Articles_keyword:
article_id
keyword_id
Table authors:
author_id
Name
Email
about
Table Keyword
keyword_id
name
?????
(I'm not sure how to organize with the keyword - each article can have multiple keywords)
I'm completely new to organizing with a database, so I have no idea what I'm doing!
Could someone, point me in the right direction of a good tutorial.
Please let me know if I need to be more specific
You can do this with WordPress. WordPress is built on top of a MySQL database, but you don't really to to mess around with it too much other than setting it up initially, if that (some hosting sites have an automated WordPress install that sets up the database for you).
Once you are all set up, then you can use Posts in WordPress for your articles and the latest article is displayed first, with links to the old ones automatically generated. If you have any static content, you can use Pages in WordPress.
Related
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 :(.
I have moved a joomla site to wordpress with fg joomla to wordpress (wordpress plugin) free version. Now i want to get the list of all of the content(articles) with their id, link, path and alias.
I am new with joomla so i also want to know the difference between the alias on new article and the alias which we give at the time to add it in menu item.
Thank in advance.
Can anybody also tell me the common attribute among the jos_categories, jos_menu and jos_content to join the table and find the list of all articles with id, alias, path and link?
The articles of joomla sites and its all required details can be found on the #__content and #__categories tables .
The article id, alias(path and links) is the url of the article.
#__content table have catid that connect which category those articles are (id in #__categories).
There is no direct connection between #__menu and #__content. the Joomla site may use an article link on the menu system with url or single article type those you can find on #__menu table with link field like com_content or something.
When you are migrating to WordPress all articles you can consider as post and its link(alias) as WordPress permalink
Hope it make sense..
I am trying to normalize my database but I'm having a headache getting to grips with it. I am developing a CMS where Facebook users can create a page on my site. So far this is what I have
page
----
uid - PK AI
slug - Slug URL
title - Page title
description - Page description
image - Page image
imageThumbnail - Thumbnail of image
owner - The ID of the user that created the page
views - Page views
timestamp - Date page was created
user
----
uid - PK AI
fbid - Facebook ID
(at a later date may add profile options i.e name, website etc)
tags
----
uid - PK AI
tag - String (tag name)
page_tag
--------
pid - Page id (uid from page table)
tid - Tag id (uid from tag table)
page_user
---------
pid - Page id (uid form page table)
uid - User ID (uid from user table)
I've tried to seperate as much information as needed without going over the top. I created a seperate table for tags because I don't want tag names being repeated. If the database holds 100,000+ pages, the repeated tags will add to storage and speed no doubt.
Is there any problems with the design? Or anything I'm doing wrong? I remember learning this at university but I've done very little database design since then.
I'd rather get it right the first time then have the headache later on.
Looks fine to me. How bad can it be with five tables?
You have users, pages, and tags. Users can have many pages; pages can be referred to by many users. A page can have many tags; a tag can be associated with many pages.
Sums it up for me. I wouldn't worry about it.
Your next concern is indexes. You'll want an index for every WHERE clause that you'll use to query.
I have an app that will allow an admin to upload an article and share it with many users to edit it. The article is then broken down into sentences which will be stored as individual rows in a MySQL DB. Each user can edit article sentences one at a time. How does one structure the database to allow admins to adjust the article sentences (merge, move, delete, edit, add) and still maintain the integrity of the the user's relationship to the article sentences?
Here is the basic structure:
article_sentences
---------------
-id (auto_increment)
-article_id (FK)
-paragraph_id
-content
user_article_sentences
---------------
-user_id (FK)
-article_id (FK)
-article_sentence_id (FK)
-user_content
One problem I see is the change in article_sentence ID. If the admin moves an article around, the ID will need to change along with the paragraph_id possibly changing if we want the article content to be in the correct order. To solve this, maybe we can add an article_sentence_order column? That way the id will never change but the order of the content is dictated by the article_sentence_order column.
What about merging and deleting? Those will cause some problems as well because fragmentation of the different IDs will start to happen.
Any ideas on a new schema design that will help solve these issues? How does an app like Google Docs deal with this type of issue?
Edit:
To solve the issue of moving different sentences around. We can use a new column called order_id and it can either be a varchar or int. Some tradeoffs: If int, then I will have to increment the subsequent sentences' order_id to be plus 1 of itself. If using a varchar, the order_id can simply be something like '3a' if I want to insert between 3 and 4. Problem with this is that in my application code, using numeric indexes to traverse to the next and previous sentences will be bit of a problem.
Are there other alternatives?
What about holding only full version of content, with a version number for each record so you will have a complete history of the article edited and by whom it was modified?
User:
- id
- name
User_article:
- id
- user_id (fk on user, this is the current editor)
- article_id
- version_number
- article_content (the full content of the article)
Article:
- id
- created_date
- user_id (the creator, or main owner )
- category_id
This way, it is very easy to revert articles content to a previous point in history, to see which user what modifications made, etc
I'm working on a project where I have the following (edited) table structures: (MySQL)
Blog
id
title
description
Episode
id
title
description
Tag
id
text
The idea is that that tags can be applied to any Blog or Episode (and to other types of sources), new tags can be created by the user if it doesn't exist already in the tag table.
The purpose of the tags is that a user will be able to search the site, and the results will search across all types of material on the site. Also, at the bottom of each blog article/episode description it would have a list of tags for that item.
I'd thought too much about the search mechanism, but I guess it'd be flexible between an OR and AND searches, if that has any impact on choices, and probably allow the user to filter the results for particular types of sources.
Originally I was planning to create multiple tag mapping tables:
BlogTag
id
tag_id
blog_id
EpisodeTag
id
episode_id
tag_id
But now I wonder if I would be better off with:
TaggedStuff
id
source_type
source_id
tag_id
Where source_type would be an integer related to whether it was an Episode, Blog, or some other type that I've not included in the structures above, and source_id would be the reference in that particular table.
I'm just wondering what the optimum structure would be for this, the first choice or the second?
In a clean (academic) design you would often see to have a supertype Resource (or something similar) for Blog and Episode with it's own table. Another table for the tags. And since it's a N:M relationship between Tag and Resource you have an extra mapping table between them.
So in such a design you would associate the Tag-Entities with your resources by having a relationship to their generalization.
After that you can put general attributes to the generalization. (i.e. title, description)
You can add attributes to the relationship between Tag and Resource like a counter how often a specific resource was tagged with a specific tag. Or how often a tag was used and and and (i.e. something like you see on stackoverflow in the upper right here)
The biggest loss in going with structure 2 is loss of referential integrity. If you can say "whatever" to that, it might be easier to go with this structure.
When I say structure 2 I mean:
TaggedStuff
id
source_type
source_id
tag_id
If I understand you correctly, the point is to optimize search mechanism...
So it has sense to make some kind of index_table and demoralize the data there...
I mean smth like this:
Url, Type, Title, Search_Field etc..
where Url is the path to the article or episode, Type (article|episode), Name (what users will see), Search_Field ( list of tags, other important data for search )
thats why both variants are quite good)))