ios - Database design for book structure (table of contents) and content -

i have list of entries, can thought of paragraphs book, stored separate objects of same class. these objects have ‘num’ property, along actual text, know order , can later display them in list in correct order (1,2,3, …).

now want bring 1 step further , able ‘record’ structure of book, table of contents. in other words, book divided chapters, , each chapter further divided sections. first few paragraphs found under ch.1 sec.1, ch.1 sec. 2, , on way ch. n, s. m. i’m not sure of what’s way record information? i've been told should use database sql i'm not sure begin.

the implementation must allow me ‘quickly’ determine following 2 things @ point: (1) given chapter , section #, paragraphs contained within section? (2) given paragraph #, chapter , section under? must flexible enough use same platform in future few edits if structure (depth-wise) of book changes (e.g. sections divided subsections, etc.). finally, should able handle optional divisions (i.e. sections have subsections while others not).

this ios app , code written in objective-c far.

sql 1 possibility. if follow route, there trade-off between flexibility , easy of coding impacts maintainability. example, if build fixed structure, additional levels attempting cater future, such as:

book   chapter     section       sub-section         paragraph 

you have code unambiguous references, such section.fk_chapter, paragraph.fk_subsection, etc. make easier troubleshoot , build queries. have problem of having refactor code fair amount if wanted add, say, sub-paragaphs, or sub-sub-sections. ui simpler code in approach know "level" working at. alternatively, can go hierarchical approach:

book   chapter     content item       content item         content item           .... 

where contentitem table has self-reference foreign key. has quite big advantage of allowing number of levels. attribute on content item tell name , "type" of level @ if needed. more flexible, come complexity in implementation , ui presentation. columns called contentitem.fk_contentitem refer parent level not tell coder in hierarchy. queries bit more difficult write. ui have cater "any" number of levels. on other hand, these problems not insurmountable , many have gone before on route.

your question quite broad, opinions vary on approach , above admittedly general.