Question

I am designing an ERD for Journal Management and Publishing System

Keeping in mind that I will have Author, Editor, Reader as the users for my application. As well as an Administrator for each Journal .

So each Journal will have its own section http://www.abc.com/journal/abc as well a separate site administration section for it. How can I make an ERD that maintains the set preferences for each Journal set by each Administrator.

I’m currently using MySQL Workbench.

Answer 1

Well, for starters, make tables based on what you expect a user to fill out in a form (adding books? Make books. Adding users? Make users). These are your “things”, and are the easiest things to start with. Just add the key fields only, however. Then, join your tables. During this process, you’ll find that you’ll need to create some intermediary tables to represent activities, relationships, or some progression that your “things” will go through throughout its life in the database. Whatever you do, don’t add superfluous fields to your tables until you have them linked up in a manner that you’re comfortable looking at. It helps because you’ll keep the fields minimal, and the tables will appear smaller, preventing you from getting as distracted when looking at the ERD.

I can’t post you a full schema. That would be silly, and a ton of work for both of us, as I’d have to ask you all the questions you should be asking anyway. Hopefully these pointers will help you build your own system yourself.

EDIT

Since you only need a single feature pointed out, I’ll help.

You’d really only need two tables – preferences, and journal_preferences. Since one journal can have many preferences, and a preference can belong to more than one journal, you’ll need that special intermediary table, journal_preferences. journal_preferences only needs two fields to work: journal_preferences.journal_id, and journal_preferences.preference_id.

So, say we have this:

SELECT * FROM journal_preferences;

journal_id    preference_id
==========    =============
1             2
1             3
1             5
2             1
2             2

This being, of course, a reference to the preference_id #’s 2, 3 and 5 for the first journal, and the first and second preferences for the second journal.

SELECT preference_id, preference_name from preferences;

preference_id        preference_name
=============        ===============
1                    auto-post to facebook
2                    auto-post to google plus
3                    auto-post link to twitter
4                    auto-post to rss feed
5                    is hidden                  

And so on. That way, you can give journals maximum options, and still keep storage costs minimal.

Some preferences need a value. This table might work if the preferences are on or off but for values, how can it be modified?

You’d only need to specify the preference_value:

pref_id   pref_name                   pref_value  pref_value_code
=======   =========                   ==========  ===============
1         auto-post to facebook       1           BLN
2         auto-post to google plus    0           BLN                 
3         auto-post link to twitter   1           BLN
4         auto-post to rss feed       0           BLN
5         is hidden                   0           BLN
6         post_as_new                 720         HRS

_{The 1’s and 0’s, in this case, are Boolean codes for True and False.}

Also are the preferences saved in the application logic? Meaning that the application will figure out to save the prefernce_id and the value against it for that particular journal id? in the table

I pointed out a possible solution to knowing how to interpret the value. And yes, your application would “know” what the possible values are by doing a lookup into a master table, if required:

SELECT * FROM preference_values;

preference_value_id   preference_value_code  preference_value_description
===================   =====================  ============================
1                     BLN                    boolean
2                     HRS                    hours