I am new to the world of data modeling, so this maybe a silly question.
I'm developing database for a tour booking website.
if we have fill same contact information on different web pages of same website as shown in image then can we have create two separate database tables for storing data or only one table is sufficient to store contact details on both pages ?
I made this DB model for this web page. Is that correct for this page or need to add one more table?
I just made one table provider_contact_details_fact for both pages and connect it with foreign key as shown in the photo attachment. Is it correct or not? please help me for finding the correct solution.
Related
Okay so I’m need guidance on where to start.
What I want to do is upon clicking a button in my web app which will be labelled “search” the web app will connect to my realism database and search the data base for the “search criteria” and the once found all matching cases it will create div blocks with the information inside it, in a list view and assign the ID of the div to the UID it gets back from the database.
database:
Users
--> Country
---->State
----->City
------>Post/ZipCode
------->UID
--------> Users informantion
Welcome to StackOverflow!
A great place to get started is the Firebase Realtime Database doocumentation or searching for Firecasts on YouTube (linked below).
As requested, here are some questions to ask yourself to get started and help scope out and define your new Firebase project.
What language are you going to use?
Are you planning on using any frameworks/libraries? e.g. For Javascript, these would include things like jQuery, Polymer, and React
What information are you storing in your database? e.g. user profiles, private user data/settings, public indexes, username lists, etc.
How is your database structured?
What data is being searched? The entire database? Values in a certain location?
What data needs to be displayed in your view?
Is the data accessible for just the current user or is it a public database that anyone can use?
What search criteria will be used? Is it just one filter at a time or many?
The answers to these questions aren't set in stone, but are to help you start thinking about the future of your project. They can be changed at any time as this isn't SQL where everything has to have its own schema.
If you intend on using "advanced searches" where you'll filter by multiple parameters at the same time, consider using Cloud Firestore instead.
I recommend looking at some Firecasts to help guide you through these questions. Here are some links to them:
Firebase YouTube Channel
Video: Getting Started with the Firebase Realtime Database on the Web
Playlist: Firebase on the Web
My question has to do with the Salesforce integration in Social Tables and is two-fold: 1. Am I correct that only objects belonging to Contacts can be imported to Social Tables? 2. Is further integration under development?
To clarify, at present it appears that Social Tables pulls contacts from Campaigns, but does not pull other campaign data - only data stored in Contact records.
To really make use of the Salesforce integration, we'd like to import event data to Social Tables fields (e.g. Table #, Seat # etc). (Our use case is a seated fundraising breakfast.) Intuitively, that would mean Campaign Member in Salesforce would need to be imported to Social Tables along with Contacts (event-specific data can't be stored that in Contact records, since the guest data and data types would vary for different events).
Similarly, it would be great to have the option to import only the contacts in a campaign that have a specific status or "Attending?" value. I know it's possible to map Salesforce fields to event-specific fields in Social Tables, so maybe I'm missing something...thanks in advance!
Let me try to answer those for you.
Am I correct that only objects belonging to Contacts can be imported to Social Tables?
This is almost correct, for a given CampaignMember of a Campaign we are currently pulling all Lead or Contact fields (depending on the type of the CampaignMember). This does not include CampaignMember fields.
Is further integration under development?
My team is responsible for Check-In and although our focus is currently not on adding SF Integration features, we weigh customer feedback very heavily when revisiting our roadmap. You make a very valid point with including CampaignMember fields with the import and I will communicate this to our product team so they can handle accordingly.
Importing a subset of members is another great feature request that we will note. Once we have CampaignMember fields included you could accomplish this by importing all members then selecting users with unwanted statuses and deleting. Not the best but will work.
Thanks for reaching out with the fantastic feedback and hope this helps answer your questions!
I'm trying to design database schema for a web app that serves as a dashboard.
There can be any number of Dashboards (User can create new dashboard)
Each Dashboard is associated with Teams (About 10-25 teams per dashboard)
Each Teams has Members (About 10 members per team)
Each Member has a name, role, email
Every Team submits weekly reports through a form (About 12 questions. All questions are same for every team except one question)
The Form responses are stored in the database.
Based on the weekly form responses, the warnings are displayed on the Dashboard (web app). There are fields like Teams issues, Number of meetings missed by a member, etc
What I've done so far
Is this the correct way to design the database? Can this be improved? I'm using Django to create the web app and SQLite3 database.
It looks like you are off to a good start. Based on your business rules that you listed, you might want expand your design based on #7. For example, you mention that team's attend meetings, yet there is no branch for this action by member.
One other area that I see for improvement is #5. Although at the start you may think there are at most 12 questions, your database model should be built to accommodate future requirements: your form responses should be composed from a minimum of four tables (Survey, Question, SurveyQuestion, SurveyResponse).
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.
I am using Titan Graph DB. I want to implement "follow" button in my page i.e I a page update something, it should be know to all follower. I dont know how does this follow mechanism work.
In social networking when we follow something we keep getting all updates from that page. How does it work? What is the idea behind implementing this in Graph DB.
Suppose I am following a page XYZ and there happend one update on XYZ. then how does it sends its update info to all followers.
Is it something that it will store update info for all individual
user in graph DB
OR Is it like when a user login it will check all page that it follow
for any new update?
OR something else
The process to trigger the notification has nothing todo with the underlying database you use. This is part of your business logic, how you design your application and how you notify all the listeners about the change.
A graph database will give you the opportunity to store the information about your users and theire tweets, or your sites and the follower in a more natural and semantic way.
In a graph database, you can store your Persons, e.g. John and Doe as Vertices and a relation or edge between them, labeled with follows. In your SQL database, you would store them in a separate table plus a table for your joins to store all the followers.
If you now have a new tweet, you have to join your tables in your SQL table to find all followers to notify. In a graph database, you just have to check the incoming edges on the person who wrote the tweet. Also, in the graph database, you could store the tweet as well, where an extra edge from the person who wrote it goes to the tweet, to have all the necessary informations for your notification at one place, instead of lots of lookups in SQL tables.