Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I need a Database to store the following information :
User : FirstName, LastName, Email, Mobile, About/Description, Type (Staff/Freelancer/Client)
Staff : Type (Designer/FE Developer/BE Developer/DB Developer/SE Optimist), Rank of Staff
(Manager/Staff/Employee), Projects worked on, Active Projects working on, Address,
Skills (HTML/CSS/JS/ASPX/PHP/DB Development/SEO/Design),
Software(Photoshop/Illustrator/In-Design/Fireworks/VisualStudio/MSQL/Wordpress)
Freelancer : Type (Designer/FE Developer/BE Developer/DB Developer/SE Optimist), Projects worked on, Active Projects working on, Address, Skills (HTML/CSS/JS/ASPX/PHP/DB Development/SEO/Design), Software (Photoshop/Illustrator/InDesign/Fireworks/VisualStudio/MSQL/Wordpress)
Client : Projects Owned, Active Projects owned, Address (Home/Work/Invoicing/Delivery)
Address : House No:, Street Address, Line 2, Line 3, County, Country, Postcode, Landline
Project : Title, Client Name, Start Date, End Date, Due Date, Status (Active, Hold, NotActive), About, Development Team (List of Freelancers or Staff working on the Project), Progress (done by Milestones : Design/FE/BE/DB/BO/SEO/Deployment)
Basically the thing I'm struggling on is how to link the different type of Address and Users etc. For example a User can be : Staff or a Freelancer or an Client, Or a staff or freelancer can also be a client. I have no idea how that would work in Database Format. The same goes for Address Types etc.
Any Help ? I'm really Stuck. Thanks in Advance.
You're asking about the basics of RDBMS design. It's sometimes called Entity-Relationship design. It's a big topic. You may want to read a book on it.
It sounds like you need a Person table with a row describing each unique person in your system.
You then need, perhaps, an Organization table with a row describing each organization (company, consultancy, freelance entity, customer, provider, etc).
A Person_Organization table could relate persons to organizations. This would implement a many-to-many entity relationship between Person and Organization. This table could contain PersonID, OrganizationID, and a field describing that person's role in that organization.
You could add a Contact table with contact information (addresses, tel nos, email, etc). It would contain a Person id in each row.
You'd have Project table with a row for each project. This would contain an OrganizationID that identified the single customer for it, as well as other material describing the project.
There'd also be a Role table with a role for each Organization playing a role in each project.
How to handle an Organization that has more than one contact address is an exercise left to you.
Please keep in mind that "too clever is dumb" in this kind of work.
You do all of this using the concept of a foreign key.
Generally, a good idea is to give each table a primary key column that will serve as an identifier for each row of data. User table would have UserId, Project table would have ProjectId, etc.
From there, you add foreign key constraints to columns in your other tables that forces those rows to map to a User. For example, your Address table would have a column called UserId that is foreign key to the User table; this key tells you that the address of that row belongs to the corresponding User.
How to build the foreign key constraints depends on your requirements and the relationships between your data; it's something that you should figure out so that you will be able to access all of the necessary information using simple queries.
Also, keep in mind that your data is hierarchical. You have a Client, Freelancer, and Staff, each of which needs an address. But all of these 3 are also users. It makes much more sense to key each of those tables to the User table, and then key the Address table to the User table as well. This allows for your relationships to be more flexible and easier to understand.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Imagine I have multiple companies, which each have multiple employees, multiple vehicles, routes, departures, captured damages and assignments(who has to drive a tour).
How should I structure my Firestore to have it simple and with an overview? The current structure looks a bit like this:
I have multiple collections, which hold all the different companies, all the vehicles, all the employees and so on...
- employees:
- employyeDocuments
- field with companyID (reference to the company document)
- field with employeeID (the uid of that employee, used for identification)
- companies:
- companyDocuments
- array of all the vehicles (each element is a reference to a vehicle in the vehicle collection)
- assignments:
- assignmentDocuments
- field with employeeID
- field with companyID
- field with vehicleID
- field with routeID (all IDs are document references to the according documents)
- routes:
- routeDocuments
- information about the route, waypoints, delivery options... (but NO companyID or employeeID, since that route should be reused and is assigned to an employee in assignments)
- damages:
- damageDocuments
- any recorded damages
There are more collections and documents, but they all follow similar rules, so they don't need to be addressed here. My question is now: Is there any better way to structure this to make it easier to read and avoid accidentally mixing up companies or employees? Or is the approach I use the right one? I am sorrowed about me losing the overview or the database becoming a complete mess.
Education would be great!
Overall, it looks like your structure appears sound but this may be a "many to many" situation and can be addressed in several ways. from experience, keeping it simple but modular has always been key.
Keeping a document with the document name being the UID for that entity is a common tried and tested solution.
simply referencing an id as the field property, an array of id's for the employees in the company, etc.
You should also manage a master employee document by merging all current employee documents into a master document for employers or HR and simply update it with a query for any new employees who may not be on the list.
This restful approach can help reduce maintenance needs and improve performance overall.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm planning to build a MVP for a real estate system using React and Firebase. I have used SQL databases in the past and hence find it difficult to understand the NoSQL concepts (collections, documents, fields).
Below are the tables I would set up in an SQL database and wanted to know how to set up the fields in Firebase. The front end client should not download irrelevant documents and we should be able to query documents across collections.
For example: What's the property address of a particular household member.
Property
PropCode
Start Date
End Date
Property Type - (House, Unit, Villa)
Property Source - ( Developer, Housing, Self)
Address ( State, Post Code\Zip Code, Suburb, Street)
Tenancy
TenancyID
PropCode - Links to the property table
Tenancy Start Date
Tenancy End Date
Tenancy Type (LongTerm, Short Term)
Household
HHID - The household ID
HHMID - The household member ID. Each member in the household is assigned an ID
FirstName
LastName
DOB
Email
HHM Start Date
HHM End Date
Household-Tenancy - Table to link household with Tenancy
TenancyID
HHID
Thanks
Jag
Well, this question is really having a vast scope and it cannot be entirely covered in one answer.
Here is my try to give you a starting point:
Note: This is for Firebase Firestore (not Realtime Database).
Firebase Firestore Schema (Brief):
In firebase, you have a collection which simply can be said as a bunch of documents. Now, what are documents? Documents are the actual place where your data reside. So for eg., you will have a collection named users which would have all the users' documents (data).
Refer here for more details: Firebase Firestore Model
Your Answer (a try):
Collection-Properties: which would contain all of the properties' documents. Each document would contain data of the property (address, unit etc..). It would also contain the type of the Property (room, house etc.) and the UID (the unique ID of a user in Firebase) of the current tenant (By this you can query for the user using his UID in the Tenants collection). The document would also contain a subcollection- Previous Tenants which would contain the documents with details of the previous tenants.
This would also contain all the demographic details of the properties, (a subcollection is recommended not a separate collection).
NOTE: Firestore document can contain at maximum 1mib, so if there is possibility of exceeding that limit then you can break down the details into subcollections.
Collection- Tenants:
which would contain all the tenants' documents. Each document would contain data of the tenant (name, rent etc) and the document ID of the property in which he is currently living (By which you can query the property). Also, it would contain a subcollection-Previous Properties which would have the details of the previous properties in which he lived.
I'm not quite sure about what you mean by rent statement but if it just means the total rent the tenant has to pay in a week, you can directly have a subcollection which would contain the tenant's weekly rent.
I hope I was able to cover you listed assets. In these cases, no one can say a correct or a wrong data structure. You just need to think of the one, which suits you best.
Additional Bonus: Advanced Data Modeling with Firestore by Example
I am currently developing a new database / web application for our school. I will need to supply a little bit of background information to make my question a little more relatable.
There are many different user types that will access this application each needing to access different parts of the application with different permissions for each “zone” they may be able to access.
For example:
A student can login and access there information and update their details as well as download copies of their reports (so they can only see their information)
A teacher can login and access there information and all the students they teach
A manager can login and access there information and all the teachers and students they manage
There are then a bunch of other login types however for this question they are not really important as they are all technically just more users which do not have or require their own table for extra information.
I have for the most part decided on a structure that I am happy with, however I keep changing my mind on how I think the following is best done.
I have a user table (User_T) where all the relevant user information is stored, (username, password, etc.)
However I also have separate tables for some of the user types (EG, Student, Staff, ETC), this is necessary because a student needs to have different information stored than a staff member.
Here is where my problem lies, all of the users will have some of the same basic fields (First name, Last name, Birthdate, Gender, etc.).
Should I store these in the User_T table? Or in the individual tables?
If I store them all in the User_T table this makes it easier to have the application pull their information and allow them to update, on the down side when displaying student details for example, I will need to reference the User_T to get the students name etc.
I am currently in the mindset that the best option is to have the separate tables with all the fields and join them in a view User_V, with a field that indicates the origin of the data so that when an update is preformed it can be applied against the appropriate table.
Thoughts?
Sounds like there would be good separation by using the User_T table as the general "people" profile table and the other tables for the unique role specific data. User_T would store the more general info about the person and the ID in this table would be perhaps a Foreign Key called "person_id" in the other tables.
Going with this table schema would also depend on how often you might query this shared general data together. For example, if you plan to search a name or email without knowing the type/role (whether staff, student, etc), then it is good to have this general people information in the User_T table apart from the other information. If you knew the role/type, you could choose the corresponding table to search in and simply JOIN as needed for the User_T data. But if you don't separate your tables this way, then you are left with using a VIEW or UNION to allow you to search on only those general columns with a single query, which in my opinion is much more troublesome to optimize.
User_T table: id, first_name, last_name, email, gender, birthdate, role, ...
Students table: id, person_id, gpa, ...
Staff table: id, person_id, staff_type, hire_date, ...
This may have been answered, I looked but honestly don't know what I should search on. because everything I search on isn't what i want.
Anyway, I am building a ASP.NET SAAS project.
This is my delima, multiple companies will be using the software. I am building it so they themselves can manage their user base.
This is all in one SQL Server DB.
Right now the way it is designed I have a user table that has userid (identity), username, password, companyfk, first name, last name, email. the primary key is userid. The secondary Primary key I say is username.
When someone enters in a user with a particular username it will search to see if that username is taken in the entire table (not based off company).
This could be a problem, I see of people trying to find usernames that work and are professional sounding for the organization.
Couple of options
Do I, have the system make the username itself and give it to them?
Do I partially make the user name and allow them to do the rest. Here I could assign each company a 3 letter abbrev and append it to the user name.
Do I make the username search also be specific only for that company. here the problem I see is when they attempt to login how will I know what company will be logging in. I don't think it is wise to advertise a drop down list of all the companies using the system on the log in page.
Do I make a helper tool like yahoo does that as they are typing it tells them if it is
taken and does a suggestion? This is the more difficult of the 5 choices.
Do I just keep it the way it is and let them deal with the headache (easiest choice of all)
I am leaning towards option (2).
And I am wondering if anyone has thoughts on this.
When in doubt, the easiest way to solve the issue is for them to supply their email address and make that their username.
Considering no two email addresses are the same, I'd say you'd have it made.
Agree with Justin on using email address as it’s the most obvious unique field.
If you really want to go with the username I’d consider requiring company ID as additional field when logging in. This was you can have two identical user names in the table but not in the company.
I'm fairly new to Access.
I have a DB table that needs to be normalized. I have some information about a person. These people are authorized to grant access to areas at our work site. Every person may be authorized several times to manage different areas, and of course different people can be authorized to manage different areas. My first try at it was to include the authorization and the areas together, but I realized that I was really repeating the data that way. After doing some study I decided that the best way to do this was to create 4 tables
tblPerson, tblPermission, tblArea, tblArea_Permission
The tblArea_Permission is a join table for the many-to-many relationship between tblPermission and tblArea (this is something that I just learned about). I seemingly set up the table relationships OK on the relationship tab. I also use a query for adding the records to the join table. When I try to do this, with a query that is getting the records from the tables, I get "You cannot add or change a record because a related record is required in table XXX." This would seem to be impossible.
I decided that I could probably live with the DB not enforcing referential integrity and took that away and used a combined primary key for the two records because every person with permission will control an area in only one combination. That seemed to work, but then I noticed that the records would randomly change. I decided that the DB must be corrupt. Parts of the DB seem to be working correctly, so I started with a new database and imported the tables and one form, then started to rebuild the new tables as described above. I got the same error.
Any help would be greatly appreciated. I've read through some different books, and used google, but nothing addresses this.
If a person is authorised to manage an area, you need a persons_area table:
PersonID ) Primary key
AreaID )
Which shows which areas the person can manage. I am not sure where the permissions table is coming from.
You will then not be able to add a record to person_areas table unless you have an ID in the area table and an ID in the persons table. If either of these IDs are missing, you will get the error above.
If you want more relevant comments on your DB design, you will need to post schemas.