|
|
| Line 5: |
Line 5: |
|
| |
|
| For other areas of active development on AniDB, check: [[Development]]. | | For other areas of active development on AniDB, check: [[Development]]. |
|
| |
| Directly related: [[Generic PersonCompany DEV]]
| |
|
| |
|
| =Vision= | | =Vision= |
| Line 90: |
Line 88: |
| ==General== | | ==General== |
| ===Manga entries=== | | ===Manga entries=== |
| * basically just a name and a summary/description of the entry
| |
| * further data can't be stored at this level
| |
| * categories/tags would be assigned on this level
| |
|
| |
| ===Editions===
| |
| * compareable to an anime entry | | * compareable to an anime entry |
| * made up of several elements (chapter, volumes, etc.) | | * made up of several elements (chapter, volumes, etc.) |
| * picture | | * picture |
|
| |
|
| ===Element Edition=== | | ===Element Relation=== |
| * to make truly reuseable we need a layer between editions and elements | | * as certain blocks are content wise identical we need a mapping table between content and manga itself |
| * release dates | | * contains meta data that is not content specific (dates, numbers, pics) |
| * volume/chapter "number"
| |
| * controls the order of elements (some internal number to shift content around) | | * controls the order of elements (some internal number to shift content around) |
|
| |
|
| ===Elements=== | | ===Elements=== |
| * compareable to an episode entry | | * comparable to an episode entry |
| | * content specific reusable elements |
| * variable element which may be a volume, chapter, omake, illustration, etc. | | * variable element which may be a volume, chapter, omake, illustration, etc. |
| * needs nesting capeabilities to build a 2 level hirachy | | * needs nesting capabilities to build a 2 level hirachy |
| * only volume/chapter(/omake?) ones should be addable to mylist; rest is mainly only in for credits and completeness sake
| |
|
| |
|
| ===Files=== | | ===Files=== |
| Line 116: |
Line 108: |
|
| |
|
| ===Mylist=== | | ===Mylist=== |
| * as files will exist on chapter level, unbound of editions, we want to store an edition id in the data record to prevent every single edition popping up in mylist; if the user really has multiple editions he will have to add those chapter as well evne if that means "duplicating" entries the listtb records | | * as files will exist on element (content) level, unbound of direct relation to manga, we want to store a mangaid in the data record to prevent every single appearance of the file/content in manga popping up in mylist; if the user really has multiple files of the same content in different manga he will have to add those files as well even if that means "duplicating" entries in listtb records. a unique key would hence need to be "uid, fid, mangaid" and not just "uid, fid" |
| | |
| | ===Credits=== |
| | * while the content of a certain element might be identical the credits for said element might differ and hence we can't apply it on element level, but have to make it manga specific. this will mainly reflect on the publishing level. considering credits for manga are quite short duplicating the records shouldn't be too much work. |
|
| |
|
| ===Credits/Character=== | | ===Character=== |
| * credits will be set on element level; we can't add a manga or edition id in this for easy access as the data wouldn't be universally useable anymore | | * as we enforce a unique content rule character can be set on element level and will hence apply for every related bit. |
| * to lessen the pain of data retrieval we will use a caching table which duplicates and condenses the data
| |
|
| |
|
| ==Database== | | ==Database== |
| [[Image:Mangadb-dbspecs2.png]] | | [[Image:Mangadb-dbspecs3.png]] |
| | |
| ===Example Data===
| |
| [http://deridiot.kawaii-shoujo.net/tmp/stuff.xls example]
| |
| | |
| ===Workflows===
| |
| ====Adding new manga====
| |
| * the add form should contain the data for mangatb, mangaeditiontb (to create the main edition as well), resourcetb, manganametb
| |
| | |
| =====Result=====
| |
| * 1 mangatb entry
| |
| * 1 or 2 manganametb entries
| |
| * 1 mangaeditiontb entry
| |
| * 0,1 or multiple resourcetb entries
| |
| | |
| =====Adding new
| |
| | |
| | |
| ===Proposed Alternative High Level Relationship===
| |
| | |
| This is here for discussion as a simpler relationship structure to see if it can withstand debate.
| |
| | |
| =====Manga=====
| |
| * Manga has_one Publisher
| |
| * Manga is_one [ Magazine | Doujin | Novel ]
| |
| * Manga has_many Volumes (at least one)
| |
| * Manga has_one Release (likely a year)
| |
| * Manga has Relationships to other related Manga just like Animes do.
| |
| =====Volume=====
| |
| * Volume has_one Manga
| |
| * Volumes has_many Chapters (at least one)
| |
| =====Chapter=====
| |
| * Chapter has_one Volume
| |
| * Chapters may_have_many Anime (aid)
| |
| | |
| Any "entry" has a minimum of 1 row in all three columns in order to be in the system.
| |
| | |
| For example say Naruto chapter 9000 was released in JUMP, NarutoFanMag and the actual Naruto Manga later.
| |
| This would be 3 manga entries, 3 volumes and 3 chapters entries in the database. This seems much easier as well as intuitive to the user. Just because a Chapter contains the same story in 3 different publications doesn't mean it needs to be the same row. It is a different physical object that just happens to have the same data (the likely won't be identical in many of the common cases).
| |
| | |
|
| |
|
| [[Category:Development]] | | [[Category:Development]] |