I have two indexes, Profile and Company. In profile it consists of user details along with userId. I have reference of userId in company index. Can I search users on company index by full name with the help of userId reference?
Company
userId:0WhaoyZhSKb6aUp181MHadWoBMM2
objectID:-Kr7JI35Zh_jSkIJw87z0WhaoyZhSKb6aUp181MHadWoBMM2
Profile
objectID::0WhaoyZhSKb6aUp181MHadWoBMM2
userName:dhcjcj
fullname:kurt angle
accountType:3
category:1
dob:996689700
email:tester31#gmail.com
fname:Kurt
gender:1
lname:Angle
What I would suggest you is to perform two calls then:
First one with the name as a search query to your Profile index to retrieve its userId
Second one with the userId as as search query to your Company index to retrieve the company
However, keep it mind that Algolia is a search engine and hence, will not provide you all the features of an RDBMS such as a JOIN that you would need in your case.
If I misunderstood your issue, could you provide us more details and your application ID in an email addressed to support#algolia.com, so that it would be easier to discuss about your specific use-case.
Related
We are creating a report that would need employee information. We have the employee ID, but we are also looking for the name and office location. Is it possible to have tableau hit people search to pull this information?
You can use Wildcard Match Filter Function to do so.
Then, when you type employee ID in the search box, it will filter it out to dashboard.
In my situation I've a bunch of nodes that represent the users
and they have relation to books they read.
This user have a property that says where they are from, and I added them to an index, based on their country.
So I would like to search in the index for users from one country, and list the books that people from there read more, some sorting by grouping.
could any one give me a help how to do this?
I'm having some trouble getting users from the index, and doing the query
Couple of assumptions based on your descriptions:
users have a country property, it contains e.g. France as value
you have a index called users and you store the user node's country property there
relationship type to connect users and books is READ
book nodes have a title property
Based on these assumptions the cypher query would look like:
start user=node:users(country='France')
match user-[:READ]->book
return book.title, count(*) as rank
order by rank desc
limit 20
side note: best approach to ask this kind of questions is to create a sample graph on http://console.neo4j.org and share your setup on SO.
I have a custom membership provider which I extended - added a couple of fields, first name, last name, adress, zip code and city.
now, these fields reside in the aspnet_Membership table so that I can easily access them when using the static Membership asp.net class.
now, I want to be able so save customer purchase order data (first name, last name, adress, zip code and city) to the database.
should I in my order model/table use a new set of fields - first name, last name, adress, zip code, city or should I create a relationship between my asp_Membershihp table and my Orders table?
Also, If i have dupe data, once a users asks for his account to be removed I wont have any orphan rows in my Orders table if I use the first method.
so, which is best, to have the user data, first name, last name, adress, zipcode, city in only one table and create a relationship between aspnet_Membership table and Orders table OR create the dupe fields in my Orders table with no relationship to the aspnet_Membership table? Pros cons?
Thanks!
/P
In this scenario, i would rather have the relationship.
Also being the data you are storing Orders (i assume at least, from the name :)) i would maintain a separate set of data on the Order, so one would optionally be able to specify different billing/shipping data than it's Identity on the site.
Another valid reason for duplicate at least some data on the Order table is to have all the necessary data relevant to an Order in the table, thus avoiding problems if the Client request his data to be deleted, and maintain the original values for that data on the order if the customer data were to change in time.
If you are able to, though, you should not actually delete User data, but have a field in which you specify if the User isActive or isDeleted.
Hi iam new in dynamo db and, with my knowledge its a non relational db ie we cant join the tables. My doubt is how we design the table structure. Please clarify with following example.
I have a following tables
1) users - user_id, username, password, email, phone number, role
2) roles - id, name [ie admin, supervisor, ect..]
a) My first doubt is we have any provision to set auto increment for user_id fields ?
b) Is this correct way of setting primary key as user_id?
c) Is this is the correct method to store user role in dynamo db? ie a roles table contains id and title and store role id in user table?
e) Is this possible to retrieve two tables data along with each user? Am using rails 3 and aws-sdk gem
If anybody reply it will be very helpful for me like a new dynamodb user
Typically with nosql style databases you would provide the unique identifier, rather than having an auto increment PK field do that for you. This usually would mean that you would have a GUID be the key for each User record.
As far as the user roles, there are many ways to accomplish this and each has benefits and problems:
One simple way would be to add a "Role" attribute to the Users table and have one entry per role for that user. Then you could grab the User and you would have all the roles in one query. DynamoDB allows attributes to have multiple values, so one attribute can have one value per role.
If you need to be able to query users in a particular role (ie. "Give me all the Users who are Supervisors") then you will be doing a table scan in DynamoDB, which can be an expensive operation. But, if your number of users is reasonably small, and if the need to do this kind of lookup is infrequent, this still may be acceptable for your application.
If you really need to do this expensive type of lookup often, then you will need to create a new table something like "RolesWithUsers" having one record per Role, with the userIds of the users in the role record. For most applications I'd advise against doing something like this, because now you have two tables representing one fact: what role does a particular user have. So, delete or update needs to be done in two places each time. Not impossible to do, but it takes more vigilance and testing to be sure your application doesn't get wrong data. The other disadvantage of this approach is that you need two queries to get the information, which may be more expensive than the table scan, again, depending on the quantity of records.
Another option that makes sense for this specific use case would be to use SimpleDb. It has better querying capability (all attributes are indexed by default) and the single table with roles as multi-valued attribute is going to be a much better solution than DynamoDB in this case.
Hope this helps!
We have a similar situation and we simply use two DBs, a relational and a NoSQL (Dynamo). For a "User" object, everything that is tied to other things, such as roles, projects, skills, etc, that goes in relational, and everything about the user (attributes, etc) goes in Dynamo. If we need to add new attributes to the user, that is fine, since NoSQL doesn't care about those attributes. The rule of thumb is if we only need something on that object page (that is, we don't need to associate with other objects), then we put in Dynamo. Otherwise, it goes in relational.
Using a table scan on the NoSQL DB is not really an option after you cross even a small threshold (up to that point, you can just use an in memory DB anyway).
I have a design question.
There are three tables: Users, Posts, and offers.
Offers and Posts are related based on the postid, and users and posts are related on user id.
Now, users will posts something, it could be something to buy or sell. Now users make an offer to buy a post that is being posted. One user can offer to buy multiple posts. So this means one user can have multiple offers for multiple posts. How can i achieve that a user has many offers for different posts. One user can have offer only one posts (meaning there will be only one offer for one post).
Looks simple but am kind a lost, any advice would be appreciated.
I think you are describing a relationship like this:
[Users]1---A---m[Posts]1---B---m[Offers]
[Users]1---C---m[Offers]
The key for relationship A (one-to-many) is userId; the key for relationship B (one-to-many) is postId; and the key for relationship (one-to-many) C is userId.
I think you are missing relationship C in your description. This will require Offers to have two foreign keys; userId and postId. The combination of userId and postId can also be the primary key for Offers because that combination should always be unique.