I have three tables:
Stories (id, category_id, sub_category_id, name, story),
Categories (id, parent_id, lft. rght, name),
SubCategories (id, name)
They are properly related and all is working fine. But now I need to find stories which belongs to specified category and/or sub_category, by name autocompleate dialog. Example: user entered "dog bone" and must search for such a name in categories/subcategories and after find all stories whitch belongs to found categories. No problem when doing many finds, but in SQL I can make one query. Can this be done in CakePHP in one find ?
Thank you very much!
there are a few options for doing this, some of them below
a) linkable behavior - https://github.com/Terr/linkable/wiki
b) bindModel - http://mark-story.com/posts/view/using-bindmodel-to-get-to-deep-relations
c) adhoc-joins http://bakery.cakephp.org/articles/view/quick-tip-doing-ad-hoc-joins-in-model-find
read up on them and see what suites your needs best.
either you solve it with the table assocations or you use "containable" behavior.
"Containable" Behavior is very easy to use and easy to implement.
Containable Behavior in Cookbook
Related
I have to create an SQLite DB that models a survey with some ordered content; this content can be a question, an image or a simple text field (just like Google Forms). Each content doesn't have anything to do with the other, except questions which can have a list of attached images to them.
What would be the best way to model this situation? I thought about creating a "Survey" table and a "Content" table that has only an integer ID, and that same ID is then "duplicated" into each table ("Question", "Image" or "TextField"), but then I think I would have to insert both values for the Content and values for a specific content (Question, Image or TextField) every time I need to insert a new content. I don't think it would be a big problem, but if there is an way to model this better, I would like some advice.
Your approach is an example of 'table per type' as defined in this answer.
Conceptually, you're saying "there are 3 kinds of content, and the one thing they share is their relationship with a survey, as captured in the content table". You might include in that table an explicit type indicator along the ID - this will make your code a little more explicit. You may also find you need to capture meta data like "status", "date_entered" etc. which is common across subtypes.
By including a type indicator column, you make it easy to find out what the type of a content item is. So, if you want to show the summary of a question, you could do something like
select content_type, count(*)
from content
where question_id = ?
group by content_type
to show the number and type of responses.
I am trying to migrate some of my bugzilla data to JEERA. I have some custom fields in bugzilla which has dynamic parent-child relationship. for exa-
Suppose I have Labels "India" "China" "Russia",
when I click on Label lets say "India", then it should fetch and show only cities from India and not all cities.
Right now , I am able to create Labels and cities custome fields in jeera but lacking dynamic nature.
I will be thankful, if anyone has any idea over this.
Perhaps Select List (cascading) custom field type would best solution here.
As a bit workaround for relate two custom fields between each other you can use ScriptRunner Behaviours. It's like a Groovy definition for frontend logic. Conceptually:
City field must contains all Cities for all Countries.
Create a Behaviour for a Country field. It means when user will change/select a Country field a Behaviour will be run.
In behaviour write code that will get currently selected country and then fulfil a Cities field based on selected country.
Useful methods: getFieldById(fieldId), formField.getValue(), formField.setFieldOptions(Iterable). API Documentation.
I think #sintasy is right.
If you want N-countries have their own cities, cascading select list just fit your requrement.
If you want N-countries * M-other-things, which have no relation with countries, two select lists will fit your requrement.
If you want more complex feature, then I don't known.
I would like to kindly ask more experience developers to give me a quick evaluation of really simple sql relation logic. I am very new on the field of databases so I don't want to make logic mistake which when found will cause me to rewrite the whole thing.
So here's the thing
I have a few products, let's say a fridge, washing machine and microwave.
To every item belong a few files: manual, quick-start guide, photos etc.
My implementation in database bases on following scheme:
1. Table 1: Product
columns here are:
name
description
2. Table 2: File
name
description
file
product (Foreign Key)
So basically I just make the connection between file and the product by giving every file a product it belongs to.
It seems a little bit counterintuitive tough yet I don't really know why.
Hence this logic is base of the whole system I wanted to ask if I didnt make some simple mistake here.
I guess that for someone experienced it will be obvious how it should be done.
Thanks in advance
Given that files and products may have a many-to-many relationship, the typical way to handle this is via the use of a junction table:
product_file (product_id, file_id)
The sole purpose of this table is to maintain relationships between products and their files. But note that none of the metadata is actually stored here. Instead, the metadata is stored in the following slightly modified file and product tables:
product (id, name, description)
file (id, name, description)
To see how this works, here is a query which finds the names of all files associated with a certain product:
SELECT
f.name
FROM file f
INNER JOIN product_file pf
ON f.id = pf.file_id
INNER JOIN product p
ON pf.product_id = p.id
WHERE
p.name = 'some product';
You might look for the following solution, or similar:
Product (ProductId, Name, Description)
CoverItem (CoverItemId, Name, Description)
File (ProductId, CoverItemId, File)
Let's say you have a fridge (ProductId=1) and a washing machine (ProductId=2).
As additional ("cover" or whatever term you like) items you define the following: manual (CoverItemId=1) and quick-start guide (CoverItemId=2).
This doesn't make any meaningful information so far, but now you should have a repository of your items you can use.
At last, you insert data to the File table, which connects a product with the cover-item. As an example, (ProductId=1, CoverItemId=1, File="D:\SomeFolder\FridgeManual.txt") would mean that there's a manual for a frigde in the path "D:\SomeFolder\FridgeManual.txt".
HTH
I was searching for an application to manage (electrical) components that complies with the following criteria:
- open source
- has a purchase-history
- allows filtering for type-specific attributes (abstract example: two categories A, B exist; following attributes belong to them: A.a, B.b, A.c, B.c; when choosing one category it should be possible to filter for those category specific attributes a or b)
- must: linux, optional platform-independant
Here is an extraordinary example: http://uk.farnell.com/
And with a sample-search: filters applied
I didn't find a program that meets the criteria and so tried to build a webapplication myself.The problems arose when trying to find a database-layout.
Here some thoughts:
-> use a table for each category, subcategory, sub-subcategory, ...
-> the most specific subcategory for a part has a reference to this part (that is in a part table)
I could not figure out if/how it is possible then to dynamically add new categories without changing all the SQL queries.
My idea was then to have a name-schema that allows me to write some code that analyzes those names and creates the query on the fly but that feels quite hacky.
Maybe someone has a reference to a database example or some tips?
(further information can be found in the edit-history, i deleted it because it blows up the post too much)
I'm trying to implement a feature similar to StackOverflow's tag feature. That a user can create a new tag, or by typing pull up a list of similar tags already created.
This is such a wonderful feature on this site and I find it sad that most sites do not have something like this. It's both robust, and yet very very flexible and best of all: driven by the community.
So I have these two tables:
Company
id
email
name
companySize
countryOfOrigin
industryid
Industry
id
description
Every time a user writes a new tag, I want to create one with a unique ID, and also be able to search for existing tags.
Will this database design allow for an easy and efficient implementation of this feature?
If not, please give a little guidance. :)
Whilst there's not a tremendous amount of information to go on, what you've listed should be fine. (The 'tag' being the 'description' field in the industry table, etc.)
As you might imagine, all of the real work is done outside of SQL, where you'll need to...
(Potentially) add new tag(s) that don't yet exist.
Associate the industry with the supplied tag(s).
(Potentially) prune previously used tags that may no longer be in use.
...every time you edit an industry.
That said, the key limitation of your proposed setup is that each company can only belong to a single industry. (i.e.: It can only have a single industry tag associated with it.)
As such, you might want to consider a schema along the lines of...
Company
id
...
countryOfOrigin
Industries
id
description
CompanyIndustriesLookup
companyID
industryID
...which would let you associate multiple industries/tags with a given company.
Update...
For example, under this setup, to get all of the tags associated with company ID 1, you'd use...
SELECT Industries.description FROM (CompanyIndustriesLookup, Industries)
WHERE companyID=1 AND industryID=Industries.ID
ORDER BY Industries.description ASC;
On a similar basis, to get all companies tagged with an industry of "testing", you'd use...
SELECT Company.name FROM (Company, Industries, CompanyIndustriesLookup)
WHERE Company.id=CompanyIndustriesLookup.companyID
AND Industries.id=CompanyIndustriesLookup.industryID
AND Industries.description="testing"
ORDER BY Company.name ASC
A very easy (if somewhat suboptimal, but it often does not matter) solution to use tags is to not have tag ids at all. So, you have:
Items
ItemId
Name
Description
...
ItemTag
ItemId
Tag
Adding a tag to an item is just adding the tuple to the ItemTag table, whether the tag already exists or not. And you don't have to do any bookkeeping on removing tags either. Just keep an index on ItemTag.Tag, to be able to quickly display all unique tags.