I just tackle with one scenario in which i want to maintain a particular record id information throughout the different tab in salesforce org.In this when i select a particular record in jqgrid using radio button all the information related to that record must be fetch in other visualforce tab.The table have different relationship with other table.
Related
I'm new to Firestore and trying to develop a data model for my app.
Background: I have a dating type of app with 3 primary ways that users will communicate with one another. Liking, dismissing, and commenting user profiles. Users likes & comments are private. In other words, only I can see who's liked or commented my profile (it's not like Social media where everyone can see who's liked a post). I'll need to be able to query users to know who's dismissed their profile so I won't show it to those users again. I'll also need to know who's liked/commented a users profile so I can query which users have liked/commented each other (they've matched)
Users can like many profiles and vice versa
Users can dismiss/skip many profiles and vice versa
Users can comment on many profiles and vice versa
I believe this means I'll need a root collection for likedUsers, dismissedUsers, and commentedUsers
Problem:
For dismissed users, I thought I'd store every single user as a Document of the dismissedUsers root collection and store every user they've skipped as a field/value pair like so...
dismissedUsers/User/user1, user2, user3, etc
The above would create the many-many relationship I want where dismissedUsers can have many users and users can have many dismissedUsers. However, I don't believe it would be scalable as the User Document would grow too large.
Question: How do I create this many-many relationship where dismissedUsers can have many users and users can have many dismissedUsers so that it's scalable and least expensive? And query it?
First of all I would ask myself why I am using Firestore, being a document database, instead of choosing a relational database. I personally love Firestore and highly recommend it. We pick a document database because it is faster and easier to use in many ways. In other ways it is a drawback because you have very limited query power. It sounds to me like your brain is working towards a relational database implementation.
Here is one solution
First of all I would try to avoid storing user data in more than one location to avoid anomalies (of course right). I would have one collection of users where I stored all user data with a unique id (best to use the one that Firestore assigns so I don't have collisions). Within each users document I would link a subcollection for dismissed, liked, been dismissed by someone else, liked by someone else etc.. I would keep a record of all users (just the user id) that they have dismissed, liked, been dismissed by, been liked by etc.. This way I can look up all data for who that user has liked or disliked and display whatever I want to that user accordingly.
Drawbacks
You will have to write twice per like, dismiss etc. Use a batch write to update both the liked and likee data at the same time.
You don't need a collection of users who liked, dismissed, or commented on another users profile. You can have one user collection which stores all users. Inside each user document you can have three array of the user ids of the users that liked, commented, and/or dismissed a user profile. Just make sure that the document ID of the documents inside the users collection matches the user id of the corresponding user.
I have an application where users fill out surveys on a regular basis.
Surveys are sent via e-mail and need to be semi-tracable, meaning, that I need to follow what kind of question categories are sent to each user on each survey. Right now after answering the survey, answers are saved in a separate table and any association to a particular user is removed to guarantee anonymity.
What I would like to achieve is a way where it is not possible to map any anwser with a particular user BUT it is possible to get all answers that any one user has submitted. We want to do this for analysis purposes to track how user's answers change over time, but at the same time preserve complete anonymity on a database level.
Users fill out surveys using several devices so private key storing on their device is not an option.
Application is written in Rails with PostgreSQL, but the solution can also involve other languages if it is not possible in ruby.
One of the simple solutions would be feeding a fixed set of user data to a hash function to calculate an identifier for that user, save it into the separate table along with the answers.
This way you'll be able to gather all submissions per user but there will be no relation to the user record.
A drawback is that if you would still want it you can trace a user by calculating all the hashes for your "users" table and associating it with the "answers" table. Unless you give up control over either "users" or "answers" entity to another team/business unit etc.
I am building out an iOS app that requires getting lists of users at different parts of the app(finding users nearby, find users that have similar interest etc) I'm displaying the list of users in collection views/table views.
I have a user structure that contains all of the user data(name, photo, list of interest, location, preferences..etc)
My question is, when I'm getting the list of users from the database, is it more cost effective to use the query function or to use the observe functions? In the list I only need to display the users photo and username. If the user wants to find out more then clicking on the cell will get more data from the larger user data table.
My options
using a query to get the users that meet the criteria for that list(say all users nearby). Then when the user clicks on the cell that interests them, get a snapshot from the database for that specific users.
My thought process is its less costly than pulling back the whole snapshot using the observe functions.
using the observe functions, getting all users snapshot data and only displaying the photo and username. If the user selects a cell send the data to the detail view.
creating a special display structure that contains only items necessary for the collection view/ table view and if the user clicks on a cell call the database again getting all of that users data.
If anyone has a point of view they could share that would be great!
Thanks
Observing in Firebase needed for making instant update, like in chats, when new message appear you need to update message list. So here, for getting list of users that fit your request, better to use queries
I am developing an app with a master-detail interface which displays a list of products that the user can drill down into. On initialisation, the app loads summary information for (1000+) products from a web service and displays it in a table view. When the user selects a particular product, the app calls the web service to get detailed info for that product and displays it in a detail view.
I want to persist this data between sessions using the Core Data framework.
I can think of two approaches for modelling this data.
Use a single Core Data entity Product containing all attributes for this object. When the table view is initialised these entities are populated with summary data. When a particular product is selected, the remaining fields are populated for that product only.
Use two Core Data entities, ProductSummary and ProductDetail with a summary/detail relationship between them. ProductSummary contains the attributes that are loaded by the table view. ProductDetail contains the attributes loaded by the detail view.
What are the pros and cons of each option? Option 1 certainly looks easier to code, but am I storing up memory usage problems for later? Would performance be equivalent?
With as many objects as you are going to have, go with option 2. Keep the data coming in and the attributes of the entity down to only what you need to display in the TV. Set up the relationship to detail and load that when the detail VC comes in.
I am doing something similar except with ~4500 rows. I only store what I need and then turn to the other entity for detail relating to the object.
So, I am using Google Contacts API to let users import their contacts from GMail.
I want the users to be able to select the contacts they want to import in my app, So currently I -
GET a XML feed of all the contacts a user has.
Parse it, and for each contact create a record in the imported_contacts table.
Display the list to the user, with checkboxes, so the user can select which contacts it wants to import.
When the user submits the form, I copy the selected contacts from imported_contacts to the main contacts table.
This works fine, but doesn't feel right. Can someone suggest a way to do so, without using a separate table(imported_contacts).
Map the contacts from XML to objects in memory. Only save them to the main contacts table after the user has selected the ones she wants.
Model View Controller.
Import the contacts into Contact objects, and store in a ContactRepository. All of this is completely in-memory, and is your Model.
When rendering this list in your View, each checkbox will have an ID which will relate to the ID of the Contact object in the Model.
When the user submits, your Controller will be able to interrogate the View for a list of the selected checkboxes (and their IDs), and then it's a case of going through the Model and creating the necessary rows in the database.