I have the need to list links on a page, grouped together by category.
In MySql this would be easy - I'd have a category table and a links table. The Links table would include a category Id. I could then loop over the entries in the category table and
query the the links table where category matches the current category.
I've been reading about model tree structures in Mongo and things seem to work a little differently (link). The basic list seems to be either store a parent or child reference in the document directly which allows you to
create a tree strcuture. I'm unsure how to use these sort of structures to output the data as I need it. I need to somehow loop over the categories and then query the links based on that.
I'm wondering if I can just take the same approach as I would have with Sql? So have a seperate categories collection and then in the links collection just have an object Id that points to the categories? I can then loop over categories and query the links table each time for all links with a matching category.
Related
There are two tables, one for Student and one for Borrowed Books. In the Microsoft Access (2010, 2013), it is easy to display a form Student based on the table Student, and other form BorrowedBooks based on the table Borrowed Books with their Record Source pointed.
How to do Form BorrowedBooks showing records for the current student showing on the Form Student one at one time? I'm looking to learn both VBA script and using the built-in controls to achieve the result.
Relationship between has been built. And it's one student to many books relationship.
One VBA approach like:
DoCmd.OpenForm "BorrowedBooks", , , "StudentID = " & Me.StudentID
The real trick is figuring out which event to put code into.
Another option is to use form/subform arrangement - main form bound to Students table and subform bound to BorrowedBooks. Have you looked at Microsoft Lending Library database template?
so if my understanding of your question is clear then you need to join operation on the tables
SELECT *
FROM
student
INNER JOIN borrowedbooks ON (The two table'S related column ie student.pk=borrowedbooks.fk)
you can also add a where clause if you want from here you can state you primary key in student table and it relationshi
I am new to Filemaker pro. I am working with Filemaker pro 13.
My database contains 3 tables:
category (fields = _pkCatID & CatName)
subcategory (fields = _pkSubcatID , _fkCatID & SubcatName)
books (many fields including _fkSubcatID)
I have no problems in conditional value lists, so making two popup menus in books layout for categories and subcategories was successful.
But I want to put both categories and subcategories in one menu/sub-menu using 2empowerfm Menu Popper plugin.
I created a new field in subcategory table to store a calculation to be used in the value list of the plugin.
The calculation is = CatName & ">" & SubcatName & ";" & _pkSubcatID .
So the returned value when choosing in books layout will be "_pkSubcatID".
The problem is CatName is not in Subcategory table, and if I choose it from the related table Category, I can't make the calculation "stored" which is a requirement to use a field in a value list.
So, I need to copy the field CatName from category table to a new created field in subcategory table. I don't know how to do it.
You just need to create a lookup field in your subcat table pointed to the category name in the category table.
Create a field in the sub-cat table called "Category"
Click on Options
Auto-Enter Tab at the bottom, check "Looked-up value"
Select the correct starting (subcat) and related (Cat) tables and select the name field for the Category.
That is all.
To populate this for existing records click into the _fkCatID field on a subcat layout after showing all records and in the menus select Records->Relookup Field Contents
#Michael Wallace answer is correct and that solution should work.
I'd add however that if the table is likely to become large (and it could do if you're cataloguing books for a library) then I'd suggest you run some tests on a fake large data to see if this menu technique holds up (especially if you are serving over a network). Running two global search fields with an executeSQL lookup for subcategory within category would be more efficient in a big data set - this technique is well described here and other places:
http://forums.filemaker.com/posts/c4ed6f9923
I recently discovered the power of using backend as a service platform in my applications they are great but the problem is there are not many tutorials to guide you through so many peculiar database structure implementation on these platforms, so I came up with this popular scenario to get some clarity
The structure is user can write a post and attach hashtags (up to 'n') to it , these hashtags could obviously be attached to many posts,this is typical many-to-many relationship scenario how would you propose the database structure for the implementation of following queries?
the user table has a location column, the query is to get all the posts for a particular hashtag within 50 miles of current user location?
popular hashtags(attached to the post created by other users) around current user location
P.S. these were some general scenarios I could think of, append any other popular scenario in your answers if you think would be helpful to the Parse community.
Parse doesn't provide a full relational database, but you can add a relational column to a data class, which allows many-to-many associations between classes. So you could, for example, have a hashtag class, and add a relation column to your post class containing its associated hashtags. Query 1 could be answered by building a query against the hashtag class , specifying the desired hashtags, then adding that as a subquery of a query against the post class. In your containing query you'd specify that you were looking for posts near the user's location. E.g.
PFQuery *tagQuery = [PFQuery queryWithClassName:#"hashtag"];
[tagQuery whereKey:#"tagName" equalTo:#"hash_tag_name"];
PFQuery *postQuery = [PFQuery queryWithClassName:#"post"];
[postQuery whereKey:#"hashtags" matchesQuery:tagQuery];
[postQuery whereKey:#"location" nearGeoPoint:userLocation withinMiles:50.0];
[postQuery findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) {
//Do something with results
}];
I can't think of a straightforward way of pulling the data for your second query out with a single Parse query. One approach would be to just retrieve the posts near the current location, and then iterate through them to determine the tags associated with each one (and count their frequency).
Another option altogether would be to just store tags as an array of strings against a post. You could then query by tag using whereKey:equalTo: (single tag) or whereKey:containedIn: (multiple tags). With this approach, you'd need to keep track of which tags existed elsewhere.
We have nested categories for several products (e.g., Sports -> Basketball -> Men's, Sports -> Tennis -> Women's ) and are using Mongo instead of MySQL.
We know how to store nested categories in a SQL database like MySQL, but would appreciate any advice on what to do for Mongo. The operation we need to optimize for is quickly finding all products in one category or subcategory, which could be nested several layers below a root category (e.g., all products in the Men's Basketball category or all products in the Women's Tennis category).
This Mongo doc suggests one approach, but it says it doesn't work well when operations are needed for subtrees, which we need (since categories can reach multiple levels).
Any suggestions on the best way to efficiently store and search nested categories of arbitrary depth?
The first thing you want to decide is exactly what kind of tree you will use.
The big thing to consider is your data and access patterns. You have already stated that 90% of all your work will be querying and by the sounds of it (e-commerce) updates will only be run by administrators, most likely rarely.
So you want a schema that gives you the power of querying quickly on child through a path, i.e.: Sports -> Basketball -> Men's, Sports -> Tennis -> Women's, and doesn't really need to truly scale to updates.
As you so rightly pointed out MongoDB does have a good documentation page for this: https://docs.mongodb.com/manual/applications/data-models-tree-structures/ whereby 10gen actually state different models and schema methods for trees and describes the main ups and downs of them.
The one that should catch the eye if you are looking to query easily is materialised paths: https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/
This is a very interesting method to build up trees since to query on the example you gave above into "Womens" in "Tennis" you could simply do a pre-fixed regex (which can use the index: http://docs.mongodb.org/manual/reference/operator/regex/ ) like so:
db.products.find({category: /^Sports,Tennis,Womens[,]/})
to find all products listed under a certain path of your tree.
Unfortunately this model is really bad at updating, if you move a category or change its name you have to update all products and there could be thousands of products under one category.
A better method would be to house a cat_id on the product and then separate the categories into a separate collection with the schema:
{
_id: ObjectId(),
name: 'Women\'s',
path: 'Sports,Tennis,Womens',
normed_name: 'all_special_chars_and_spaces_and_case_senstive_letters_taken_out_like_this'
}
So now your queries only involve the categories collection which should make them much smaller and more performant. The exception to this is when you delete a category, the products will still need touching.
So an example of changing "Tennis" to "Badmin":
db.categories.update({path:/^Sports,Tennis[,]/}).forEach(function(doc){
doc.path = doc.path.replace(/,Tennis/, ",Badmin");
db.categories.save(doc);
});
Unfortunately MongoDB provides no in-query document reflection at the moment so you do have to pull them out client side which is a little annoying, however hopefully it shouldn't result in too many categories being brought back.
And this is basically how it works really. It is a bit of a pain to update but the power of being able to query instantly on any path using an index is more fitting for your scenario I believe.
Of course the added benefit is that this schema is compatible with nested set models: http://en.wikipedia.org/wiki/Nested_set_model which I have found time and time again are just awesome for e-commerce sites, for example, Tennis might be under both "Sports" and "Leisure" and you want multiple paths depending on where the user came from.
The schema for materialised paths easily supports this by just adding another path, that simple.
Hope it makes sense, quite a long one there.
If all categories are distinct then think of them as tags. The hierarchy isn't necessary to encode in the items because you don't need them when you query for items. The hierarchy is a presentational thing. Tag each item with all the categories in it's path, so "Sport > Baseball > Shoes" could be saved as {..., categories: ["sport", "baseball", "shoes"], ...}. If you want all items in the "Sport" category, search for {categories: "sport"}, if you want just the shoes, search for {tags: "shoes"}.
This doesn't capture the hierarchy, but if you think about it that doesn't matter. If the categories are distinct, the hierarchy doesn't help you when you query for items. There will be no other "baseball", so when you search for that you will only get things below the "baseball" level in the hierarchy.
My suggestion relies on categories being distinct, and I guess they aren't in your current model. However, there's no reason why you can't make them distinct. You've probably chosen to use the strings you display on the page as category names in the database. If you instead use symbolic names like "sport" or "womens_shoes" and use a lookup table to find the string to display on the page (this will also save you hours of work if the name of a category ever changes -- and it will make translating the site easier, if you would ever need to do that) you can easily make sure that they are distinct because they don't have anything to do with what is displayed on the page. So if you have two "Shoes" in the hierarchy (for example "Tennis > Women's > Shoes" and "Tennis > Men's > Shoes") you can just add a qualifier to make them distinct (for example "womens_shoes" and "mens_shoes", or "tennis_womens_shoes") The symbolic names are arbitrary and can be anything, you could even use numbers and just use the next number in the sequence every time you add a category.
This may be a very simplistic question, so apologies in advance, but I am very new to database usage.
I'd like to have Postgres run its full text search across multiple joined tables. Imagine something like a model User, with related models UserProfile and UserInfo. The search would only be for Users, but would include information from UserProfile and UserInfo.
I'm planning on using a gin index for the search. I'm unclear, however, on whether I'm going to need a separate tsvector column in the User table to hold the aggregated tsvectors from across the tables, and to setup triggers to keep it up to date. Or if it's possible to create an index without a tsvector column that'll keep itself up to date whenever any of the relevant fields in any of the relevant tables change. Also, any tips on the syntax of the command to create all this would be much appreciated as well.
Your best answer is probably to have a separate tsvector column in each table (with an index on, of course). If you aggregate the data up to a shared tsvector, that'll create a lot of updates on that shared one whenever the individual ones update.
You will need one index per table. Then when you query it, obviously you need multiple WHERE clauses, one for each field. PostgreSQL will then automatically figure out which combination of indexes to use to give you the quickest results - likely using bitmap scanning. It will make your queries a little more complex to write (since you need multiple column matching clauses), but that keeps the flexibility to only query some of the fields in the cases where you want.
You cannot create one index that tracks multiple tables. To do that you need the separate tsvector column and triggers on each table to update it.