I've been having some trouble setting up the database relationships for a Vue.js/ExpressJS project, I'm looking for some advice on it please.
My ERD at the moment:
My main concern is with the user messaging relationships/setup. The many-many relationship between 'Users' and 'Room' doesn't seem right, but I don't know how to do it differently, there's always going to be many (2+) users in a conversation, and users can of course always participate in many conversations. I feel like I might be thinking about it all wrong. Is the 'Conversations' table redundant even, should messages just relate to 'Room'?
Also, should I have separate tables for item categories and quality, or just have them in the Items table as types/strings that are limited to specific words by the application?
If there's anything else as well that anyone notices that I should or shouldn't do, please do let me know.
Thank you.
Related
I am working on a database schema for a Laravel project and am unsure of how to design it properly. I have mocked up the majority of the schema, but am unsure of how to make the last leap to properly include users.
There are 8 tables, and the business model is meant to keep track of medical practices, the doctors assigned to them, their patients, the RXs that are written on those patients and what Meds are written in the prescriptions.
Where I come into the issue is that our users table will include our business' staff, representatives, sometimes the distributors of those representatives, and a select few doctors that will want to view their own production. So the users is a mixed bag of people spread across the Distributors, Reps, and Doctors tables with a few of our staff thrown on top of it. Thus far, I have created a 'UserRole' column in the Users table to reflect what the user's capacity is, but that is all.
Can someone assist me with how this should be reflected in the schema, and any thoughts on how to optimize the schema overall if they have any ideas? I am very, very new to both database design and Laravel. Thank you!
There are usually a number of ways to go about this but I followed an approach recently that provided a lot of flexibility for me.
So my simple approach is to keep the Users table as a base. With the minimum required user data like name, username, password, email, phone number, created_at etc and the User ID (user_id) would serve as foreign key to be used anywhere else that actually apply to all users.
From there, when creating a doctor profile, or a distributor etc, you follow the same user structure.
Hope this helps.
I am an unexperienced computer science student and while making projects for different courses a few conceptual questions occurred.
Say I am to develop a website similar to imdb, but for music, from scratch and I want to list some artists on the frontpage.
The database schema is already done with all its relationship and attributes, and there is a table artists.
Should my server-side artist-class contain all table columns and relationships at creation time even it is not necessarily needed at that time?
Or should I construct these objects with minimal parameters (like id, name) and get all the rest when needed (resulting in more individual sql statements) via helper-methods?
I know that there is maybe no definitive answer except for 'it depends' or boils down to personal preference, but maybe there is even a consensus.
If someone could name or link to resources to read up on things like this I would be very grateful, I didn't know what to search for exactly. Thanks.
PS: For people wondering why I don't ask these questions in the CS course; they are mostly held by students/assistants who only had to pass the course and don't have that much experience themselves.
I am not sure what this means so I am answering assuming this does not exist in the question. Will edit answer when clarification is given.
Or should I construct these objects with minimal parameters (like id, name) and get all the rest when needed (resulting in more individual sql statements) via helper-methods?
Actual answer starts here
It does not boil down to personal preference but whether you can or cannot find a practical reason to do something. All design patterns follow practicality instead of personal preferences. Even if there is a consensus you can always ask why.
If there are 100 tables in the database already present and in my web application I can get by with just 2 of them I don't see a reason why I should sit down and create all 100 tables in my web application's domain model. It's just not logical.
There may be some cases when a big application is being created and we are like 99% sure that we will need to model all of it and that requires us to model a bit more classes (say 5 instead of 2) for ensuring that our future work is not hindered.
Also there is the concern of data integerity. Does those 2 tables depend on some other table? Do some table depend on them? If there is a dependency then you might need to include those tables also.
FYI such questions are better suited on programmers stackexchange
I am working on my first web project. I have referenced many tutorials and pdfs but all those had simple examples for the login and sign-up feature for a webpage, which only used a single database. I am having a massive confusion on whether or not, the login and sign-up should have separate databases.
My main question is : The project intakes user's personal information(name, email, address, telephone number, etc.) along with information specific to their vehicles (model, company, make, manufacture date, etc.). And after logging into the website, both these data's are important but only some of them are in use like, the user's name, his/her address, the model of vehicle, and the company. So should I maintain separate databases for both of them and reference each element with a foreign key while working on databases ?? Or should i just bother less and use a single database and complete my login and sign-up function ??, because with the no. of columns that I have apparently is very large.
This might be a bit too academic, but a word you'll want to learn well is normalization. Here is a link to a pretty stiff definition: https://en.wikipedia.org/wiki/Database_normalization
This being your first web project, my advice would the following:
Don't be afraid to make mistakes. I would strongly encourage trying approaches you think are good and then don't be afraid to change your mind. The lessons learned will stick with you.
Keep everything simple up front. Only add complexity when you need it.
Definitely don't be afraid to grow horizontally with tables (add more and more tables). When I first started working with databases I was afraid to have too many tables because it felt wrong. Try to resist the temptation to cram everything in one table.
Definitely separate login, users and vehicle information. Not a bad idea to also separate out user address information since people can have more than one address.
You must use the same database for holding all the information for your project. Two different database is not really good idea , you can create many tables in an database. and each table is designed to hold different information.In case of your example you may choose the following tables in the same database
UserLogin [store login information]
User [ store personal info]
Vehicle
and so on
There must be one to one relationship between UserLogin and User table and one to many in user - Vehicle table
One user may have many Vehicle
Hopefully it will help
Can someone please gimme an example of both? I am super confused between the two :(
Are they same??
I am not an expert on the subject but from what I have read it seems that a context diagram is more interested in grouping and relating data based on the context from a user's point of view. So while a client may have an address, name, phone, etc. it will not relate those to the client. Instead the context diagram will relate the address, name, and phone along with a complaint description, subject, and issue category.
The erd on the other hand is more concerned with how the data is related. So the client has a 1 to n relationship with complaints and the complaints has a 1 to 1 relationship with descriptions, subjects, and complaint categories.
An erd is probably more useful to a database designer to make sure that the database can support the relationships correctly.
A context diagram (from what I understand) would probably be more useful to a web developer or interface designer so that they can pull the correct data into certain views or forms.
I have seen many articles and questions about how to implement a unique constraint in appengine, but I actually didn't found any explanation about why this feature is not present.
If appengine developers considered it would be better not to implement such a feature, i believe they had good reasons, but i'd be interested in understanding why they decided so.
Was this decision guided by performance concerns? Why?
Any detailed explanation about this would be greatly appreciated.
As that post linked here http://code.google.com/p/googleappengine/issues/detail?id=178#c14 says, the distributed nature of datastore makes it difficult to enforce a unique constraint. If two app instances simultaneously try to create an entity, each with a property that should be unique, the only way to enforce this would require some kind of coordination throughout all machines in the datastore.
Imagine a room of 26 people each with a piece of paper, say with a table of pets and their owners. Each person controls every pet with a different letter of the alphabet, e.g. person 1 does everything starting with the letter A, person 2 does all the things starting with the letter B, and so on.
If you wanted to make sure that a pet named mittens was the only mittens in the entire datastore, this is easy because only one person in the room will be involved, and they will be able to check their piece of paper to make sure that mittens isn't already there.
If you wanted to require that owners must be unique too, you can imagine that every time someone wants to write an entry in their table, they need to check with /every single other person/ to make sure that nobody else has that owner name used. This is the fundamental reason that app engine's datastore does not allow uniqueness constraints on anything except entity keys. It would simply not be possible to do it when the datastore contains thousands of servers.
Hopefully you can see why this limitation exists, and hopefully my late-night typing isn't too difficult to read :D
You can see a response from Google on adding unique constraints on their issue list for GAE.