I need to create 2 more tables with purpose: one table will store tags and categories data (categories can have a hierarchy but tags are not) and another table store relationship between tag, category and content. But I so confused about name of those 2 tables. I'm really a newbie in web development. After googling a bit, I found some words like term, taxonomy terms and vocabulary from drupal and wordpress. But I have no idea what they mean. Can you explain those words and help me give a name for my two tables. Of course if those tables are not well design for my purpose please guide me too.
content{
content_id
...
}
table_A{
type (tag, category, ...)
name
parent_id
}
table_B{
table_A_id
content_id
}
With relevance to wordpress, those words are indeed confusing. If you are using wordpress to build a site, you shouldn't need to worry about the database tables for storing taxonomies and terms as it has built in methods to handle all that.
You'll notice when you're in the wordpress admin panel editing a page or post that there is by default a box on the right which calls itself "Categories" and allows you to create new categories. Once one is created, you can add your posts or pages to any "Categories" you've created. I'm sure you understand that already.
As wordpress releases were built, people started asking for more customizing control over categorizing their content. So developers added "custom taxonomies" to wordpress. For clarity, I should mention that "Categories" is the name of a default "Taxonomy" built into wordpress.
A taxonomy is a group of terms. So when you create a "Category" in the right hand box of the admin panel (say "news" for example), you are creating a "term" named "news" which belongs to the "Categories" taxonomy.
This allows a developer to define their own taxonomy (let's say "products") and associate it with pages, posts or any other "post type". So if it's associated with just plain regular "posts" in the admin panel. A box exactly like the existing "categories" box would show up upoon editing but would call itself "products" instead. Anything added to that list would be a term under the "products" taxonomy.
Hope this clarifies things a bit for using wordpress. These terms can be used differently in different contexts so nothing I've said necessarily applies to anything outside of the wordpress package. Unfortunately there is often no universal "web development" meaning for a given word you may see thrown around in discussion.
Taxonomy, last time ago, means categorize life organisms. Similarly, in computer engineering, taxonomy means categorize terms, can be substantive(three, car, cat), verbs(go, be, do). Taxonomy and terms can be mens anything, but the concept is a data structure and hierarchy
Related
What implications would there be between these two structures?
Name = PROPERTY in the sub-CATEGORY of Woman in the CATEGORY of People
and
Name = sub-PROPERTY of the PROPERTY of Woman in the CATEGORY of People
I am particularly interested in how structuring my data now will affect how I am able to do searches later using Semantic Forms, inline queries, concepts and compound queries etc
SMW largely removes the need for categories. However, categories are still very useful for administrative purposes. As for me, I normally use a category for each page type that uses a unique form. In your case that would translate to a category for people (assuming you have a specific form for people). For querying, it will make no difference.
(Copied svick's answer which seems complete enough.)
While https://www.semantic-mediawiki.org/wiki/Help:Special_property_Subproperty_of states in reference to "Subproperty of":
...a query for pages with the property should also return pages that have the subproperty
...there does not seem to be any equivalent "Category of" for Semantic Mediawiki or Mediawiki, so you may not be able to do nested searches of categories (e.g., if "bread" is a "food" category, a page listed under "bread" won't be found by a "food" category search unless under "food" also).
I recall some extension allowing this (though it was expensive), but I can't find it now. Scribunto does allow pagesInCategory and using the DynamicPageList extension, our site defined a module for listed out (as opposed to searching) categories within a category: https://me-pedia.org/index.php?title=Module:CategoryList , but there unfortunately seems to be no built in way to search through categories.
I've inherited a site with a very big hierarchical taxonomy:
Vocabulary name: categories
--term: company name
---- many child terms
-- term: country
---- many child terms
-- term: issue
---- many child terms
I realized it would be easier to create Search facets and Views with appropriate content if I set up each of these parent terms as their own Vocabularies:
company
country
issue
So I created the new Vocabularies and used Taxonomy Manager to shift all the sub-terms to their new vocabularies. I then updated the Article node content type to be associated with these 3 vocabularies.
Unfortunately I also noticed the term relationship between the Article nodes (all 4,000 of them) and the Terms was now lost in the display. I thought this relationship would have been maintained by the Taxonomy Manager module.
I've been searching for a way to update the vocabulary references for the Article nodes, but I'm still not sure how the vocabulary is associated with the node. I see new field_data_field_vocabulary-machine-name tables are created for each new vocabulary - and this is where the termID and node/entity ID are associated. However I don't know how to update the Vocabulary for a node automatically when I move a term from one vocabulary to another.
I've recently move this site from Drupal 6 to 7 so it doesn't help that there are a lot of dead tables from D6 cluttering up the database.
--
I've now set up a new standard D7 install and am looking at the db default tables trying to figure out where the Vocabulary/Node relationship gets defined. On my old db the TermIDs still seem to be correctly associated with the Nodes in the Node table... but I don't see where the VocabularyID/TermID/NodeIDs are stored/updated.
Please try this module: http://drupal.org/project/taxonomy_manager
This module provides a powerful interface for managing taxonomies. A vocabulary gets displayed in a dynamic tree view, where parent terms can be expanded to list their nested child terms or can be collapsed.
The Taxonomy Manager has following operations and key features:
dynamic treeview
mass deleting
mass adding of new terms
moving of terms in hierarchies
merging of terms (using the Term merge module in 7.x)
fast weight changing with up and down arrows (and AJAX saving)
AJAX powered term editing form
simple search interface
CSV Export of terms
i18n support for multilingual vocabularies (per language terms)
Double Tree interface for moving terms in hierarchies, adding new translations and switching terms between different vocabularies
For using the Taxonomy Manager you should have JavaScript and automatically load of images enabled in your browser.
-> but I'm still not sure how the vocabulary is associated with the node
In Drupal 7 taxonomy references are done very differently than they were in Drupal 6. If you want to associate a vocabulary with a node in Drupal 7, you have to add that term as a field on the content type:
Go to admin/structure/types/manage/article/fields where you can add/delete/modify fields for your article content type
Add a new field, name it whatever you'd like, and make sure you choose type 'Term reference' from the drop-down
Make sure you choose the correct vocabulary for it to pull from
Repeat this step (add two more fields) for the remaining two vocabularies.
Go to admin/structure/types/manage/article/display and modify whether you want these new fields to be displayed on the node or to be hidden
=============== Addition ==================
In Drupal 7, since terms are just like any other field, you'll see the relationship in the DB (of course -- only once you add the appropriate term reference field to your content type) in a newly created table that stores the information about that field. For example, it may be called field_data_field_tags for the standard 'tags' vocabulary that comes with Drupal 7 by default. In that table you'll see the columns entity_id (that's the node's id) and field_tags_id (that's the term's id), but that column may have a different name for your specific term. So you would have three separate tables for each of your terms' relationships to your node, since they would be three separate fields in Drupal 7.
Does that help a little more?
I think you should :
Create new vocabularies
Add fields with term reference to new vocabularies
After you connect content type with new vocabularies, then you
should move terms to new locations
I tested and it works for me with this order.
So, it may be best to just try it out and see through some trial and error, but I'm trying to figure out the best way to migrate a pretty simple structure from mysql to mongodb. Let's say that I have a main table in mysql called 'articles' and I have two other tables, one called 'categories' and the other 'category_linkage'. The categories all have an ID and a name. The articles all have an ID and other data. The linkage table relates articles to categories, so that you can have unlimited categories related to each article.
From a MongoDB approach, would it make sense to just store the article data and category ID's that belong to that article in the same collection, thus having just 2 data collections (one for the articles and one for the categories)? My thinking is that to add/remove categories from an article, you would just update($pull/$push) on that particular article document, no?
In my opinion, a good model would look like this:
{"article_name": "name",
"category": ["category1_name", "category2_name", ...],
"other_data": "other data value"
}
So, to embed the category names directly to the article document. Updating article categories is easy, but removing a category altogether requires modifying all articles belonging to the category. If removing categories is frequent, then keeping them separate might be a good idea performance-wise.
This approach makes it also easy to make queries on the category name (no need to map name to id with a separate query).
Thus, the "correct" way to model the data depends on the assumed use case, as is typically the case with mongodb and other nosql databases.
If you have access to a Mac computer, you could give the MongoHub GUI a try. It has an "Import from MySQL" feature.
I have a site nearing structural completion. Essentially, it's made up of Users and Photos. However, Photos have a LOT of HABTM relationships, most of which are different kinds of tags, and others being categories, collections, etc...
My client would like to be able to have a conditional CMS based off the content being viewed for different promotional purposes or whatnot. For example, if a user is browsing the Category "Leprechauns", he may want to show html content about St. Patrick's Day or something. He may even want to easily include the browing user's name, if available. In which case, it'd be nice to have some sort of templating system. The part that makes this tricky is that these are small blocks of HTML for something like a 300x300 space in the sidebar and is NOT the primary content.
I've looked into refinery, but it seems to be too much of a complete solution. I've also thought about building in from scratch, but I don't know where to begin with treating dynamically generated pages (such as a new Category) as a recognizable object in Rails. I'd like to keep it more global than a slew of HABTM relationships, but it's looking like that might be where I'm heading. Ideally, he'd be able to make some HTML and check off "I'd like this to show on x and y Category page and b and z Collection page and for the tag Foo and for the tag bar as well as on my homepage"
Any suggestions? I'm open to finding a gem or getting a solid start on a homebrew.
UPDATE
I'm thinking of setting up some models Like the following:
cms_contents
============
id:integer
contents:text
timestamps
cms_associations
================
id:integer
cms_content_id:integer
model_id:integer
record_id:integer #optional
secondary_model_id:integer #optional
secondary_record_id:integer #optional
models
======
id:integer
name:string
Where:
cms_content would contain the HTML.
cms_associations would be an ActiveRecord model using has_many, :through
models would contain a the models the CMS content could be associated with
if record_id is not given, it associates with the model index
if record_id is given, it associated with the record of the provided model with that
id
if secondary information is given, a combination is created for other many to many
relationships
eg:
User has_many :photos
Browsing Photos for User(10)
model_id => #User model Id
record_id => 10
secondary_model_id => #Photo model id
So you could customize the content for browsing photos for specific users such as featured users or companies that may pay for advertising.
Any thoughts on this structure?
It's actually not that complicated. This is what you should do:
Introduce new object in the DB, name it htmlchunks
For every object that you'd want to associate with htmlchunks, create a join table and define habtm relationship
Modify your sidebar (for objects that have association with htmlchunks) in a way that they recognize whether there's htmlchunk associated with this particular object. For example, let's say you have a htmlchunk called "April Fools' Day" that contains simple html paragraph. In the sidebar, you'd just ask something like #category.htmlchunk? and output according to the result. You'd ideally place all this in a partial
As for creation of the htmlchunks you'd just offer simple wisiwig editor and ability to select any number of tags, categories, whatever. You'd create habtm entries between them and htmlchunks during the creation process
Let me know if you have further questions in the comments.
It's almost as if the almighty Ryan Bates is looking out for me, but the latest Railscast is on CopyCopter, which does exactly what I'm looking for, and runs as a separate app, so I don't have to worry about bogging down my main app. I suggest anyone who finds this to watch the screencast, as it seems pretty impressive.
http://railscasts.com/episodes/336-copycopter?autoplay=true
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)))