^NOTICE: This package is in development and not ready for live use. It is only available for bitweaver release R2. If you would like to help in developing this package you can check out module _bit_yellowpages from cvs. Talk with wjames5 or Lugie on IRC about contributing code.^
|
|
+!ToDo's |
+* Create tpls that match table schema |
+* How to verify hours data for each day in BitYellowPages |
+** loop through for days 0-6 ? |
+** require edit cycle for each day ? <-- easiest to build |
+ |
!Tables Schema
|
-This section is an attempt to clarify how the database structure will look running the listings package. This is a rough draft, and I will omit some things like id_seqs for now, and names of these things should change to meet bitweaver specifications.
|
+This is the data tables schema for the yellowpages package. This does not include some things like id_seqs which will be derived as appropriate. |
|
+!!Non-YellowpagesPackage Tables |
* __liberty_content__
|
** tracks user ownership of the listing
|
-** holds title of thing listed
|
-** holds general description to accompany the listing
|
+** holds title, description, body text |
** etc, magical liberty structure
|
-* __yellowpages_types__
|
-** numerical value (linked in listings)
|
-** types to be determined by admin
|
-*** person
|
-*** business
|
-*** item
|
-*** historical site
|
-*** personal...
|
-* __yellowpages_groups__
|
-***group_id
|
-***king_content_id <-- a primary listing of a group of listings keyed to a yellowpages entry/liberty_content entry
|
+*__geo__ |
+** adds global position data |
+**joined on liberty_content |
+* __categorization__ |
++ will rely on pigeonholes or a duplicate of pigeonholes that is exclusive for listings use. |
+!!YellowpagesPackage Tables |
+* __yellowpages_group_kings__ |
+**group_id (keyed to a pigeonhole) |
+**king_content_id (a primary listing of a group of listings keyed to a content_id) |
* __yellowpages__
|
-** holds content_id on liberty_content
|
-** provides "type" of listing
|
-** holds associated listing id/content id
|
-** url to link to
|
-** title for url
|
-** phone
|
-** cell phone
|
-** email address
|
-** fax
|
-** title of address (what the location is to them)
|
+** content_id (keyed to same on liberty_content) |
+**yellowpages_id (pretty) |
+**parent_id (optional - a content_id) |
+**description |
+** url |
+** email |
+** im_id (chat id) |
+** im_type (chat network) |
+** address |
** city
|
-** state/province (perhaps we can check user country to figure out what to call this)
|
+** state/province (check what other countries and services call this) |
***need codes
|
**country
|
** postal code (this is a universal term)
|
***international
|
***index for fast search
|
+*__yellowpages_persons__ |
+**yellowpages_id |
+**firstname |
+**lastname |
* __yellowpages_hours__
|
-**day (1-7)
|
-**start time
|
-**end time
|
-**24hrs boolean
|
-**note for special cases - this should go somewhere else or be day 8?
|
-*__geo__
|
-** adds global position data
|
-++ problem is geo is attached on a content id basis, but would like to have multiple per address - each address may need to be its own yellowpages item.
|
+**yellowpages_id |
+**day_id (0-n joins on yellowpages_days |
+**start_time |
+**end_time |
+**twentyfour (boolean) |
+**note (every day can have its own note? this is handy for holidays but over kill for the others.) |
+*__yellowpages_days__ |
+**day_id |
+**day_title |
+++defaults: 0:Monday - 6:Sunday, 7:Holidays (generic), 8:Christmas, etc |
+* __yellowpages_phones__ |
+** yellowpages_id |
+** phone_type |
+** phone_number |
+ |
|
!Brainstorm Discussion:
|
!!Schema
|