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
Related
I'm working on a school register system (it's my first PHP project) and I want it to be available not just for one school. I guess that each school should have its own database. So what I did is that after the user signs up a new school and clicks a "Create a new school register" button, a new database is created with empty tables for teachers, students, attendance etc.
At the same time I have a whole other database with just one table to store all the different schools that are going to sign up. I need it for checking if email already exists and so on.
It works but I sense that this is not how it should be done. Or is it? The app uses one hard-coded database name and then other database names are created by the user. (I've made it so the dynamically created db names have a 'school_' prefix and whatever the user names the school is then appended to it. White spaces are replaced by undescores.)
Do I need to change my approach? Thanks!
There are pros and cons for both approaches and you have to evaluate what is more important to you and how you believe the project is going to evolve.
Pros for having separate databases:
Easier to customize the installation for each school - imagine you get a school that has special requirements, and the easiest way to implement them involves adding columns to tables
Easier to migrate a school to a separate installation of the app - imagine a school gets new management and insists on on-premises hosting after a year
Pros for having a single database:
Easier to upgrade: if a new feature means you need to change the database schema, you only have to change one schema, not one per school
Easier to produce global cross-school statistics: suppose you want a report that has information from different schools - with a single database you only need to run one query, with separate databases you need one query per database
You may also want to think about how you version the source code. If you'll maintain separate versions of the source code for each school so that you can have custom features per school, it makes sense to have separate databases. If you only want to maintain a single version, then it'll probably be easier to have a single database.
I guess it depends on what the requirements are, but I think the simpler approach would be to have a single database. When a new school is created, add an entry to the “schools” table. Have a foreign key “school_id” in each table that links to the “schools” table.
I recently read a tweet that suggested that if one wants to avoid headaches in the future of an app, they should have the user table have only authentication information and a user profile table for everything else. That is if you have bikes and peaches in the system they should be linked to the user that owns them via the user profile id. The tweet was not clear on what the consequences of using the user profile. Are there maintainability/scalability repercussions to not following this especially in a large web app?
Well, don't take it as a dogma, though it isn't completely worthless. Dependency is a problem: if you have to have a lot of different data that represent particular user, you'll change underlying database oftenly. In case everything is stored in a single column, you might find yourself doing repetative monkey job of "making it work" with your types/ORM and whatsnot gonna be involved in DB <-> RUNTIME communication.
It is all about splitting complicated task into smaller less complex subtasks: auth is self-standing - one of the most important - task itself and it definitely deserves some dedicated space. However, your app might be not that big, or not that concerned with users, and thus it won't be very helpful to split data into multiple columns. You must develop a deep sense of purpose and measure when it comes down to a software design.
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'm in the planning stages of building a SQL Server DataMart for mail/email/SMS contact info and history. Each piece of data is located in a different external system. Because of this, email addresses do not have account numbers and SMS phone numbers do not have email addresses, etc. In other words, there isn't a shared primary key. Some data overlaps, but there isn't much I can do except keep the most complete version when duplicates arise.
Is there a best practice for building a DataMart with this data? Would it be an acceptable practice to create a key table with a column for each external key? Then, a unique primary ID can be assigned to tie this to other DataMart tables.
Looking for ideas/suggestions on approaches I may not have yet thought of.
Thanks.
The email address or phone number itself sounds like a suitable business key. Typically a "staging" database is used to load the data from multiple sources and then assign surrogate keys and do other transformations.
Are you familiar with data warehouse methods and design patterns? If you don't have previous knowledge or experience then consider hiring some help. BI / data warehouse projects have a very high failure rate and mistakes can be expensive.
Found more information here:
http://en.wikipedia.org/wiki/Extract,_transform,_load#Dealing_with_keys
Well, with no other information to tie the disparate pieces together, your datamart is going to be pretty rudimentary. You'll be able to get the types of data (sms, email, mail), metrics for each type over time ("this week/month/quarter/year we averaged 42.5 sms texts per day, and 8000 emails per month! w00t!"). With just phone numbers and email addresses, your "other datamarts" will likely have to be phone company names, or internet domains. I guess you could link from that into some sort of geographical information (internet provider locations?), or maybe financial information for the companies. Kind of a blur if you don't already know which direction you want to head.
To be honest, this sounds like someone high-up is having a knee-jerk reaction to the "datamart" buzzword coupled with hearing something about how important communication metrics are, so they sent orders on down the chain to "get us some datamarts to run stats on all our e-mails!"
You need to figure out what it is that you or your employer is expecting to get out of this project, and then figure out if the data you're currently collecting gives you a trail to follow to that information. Right now it sounds like you're doing it backwards ("I have this data, what's it good for?"). It's entirely possible that you don't currently have the data you need, which means you'll need to buy it (who knows if you could) or start collecting it, in which case you won't have nice looking graphs and trend-lines for upper-management to look at for some time... falling right in line with the warning dportas gave you in his second paragraph ;)
i have a database that already has a users table
COLUMNS:
userID - int
loginName - string
First - string
Last - string
i just installed the asp.net membership table. Right now all of my tables are joined into my users table foreign keyed into the "userId" field
How do i integrate asp.net_users table into my schema? here are the ideas i thought of:
Add a membership_id field to my users table and on new inserts, include that new field in my users table. This seems like the cleanest way as i dont need to break any existing relationships.
break all existing relationship and move all of the fields in my user table into the asp.net_users table. This seems like a pain but ultimately will lead to the most simple, normalized solution
any thoughts?
I regularly use all manner of provider stacks with great success.
I am going to proceed with the respectful observation that your experience with the SqlProvider stack is limited and that the path of least resistance seems to you to be to splice into aspnet_db.
The abstract provider stack provides cleanly separated feature sets that compliment and interact with each other in an intuitive way... if you take the time to understand how it works.
And by extension, while not perfect, the SqlProviders provide a very robust backing store for the extensive personalization and security facilities that underly the asp.net runtime.
The more effort you make to understand the workings of these facilities, focusing less on how to modify (read: break) the existing schema and more on how to envision how your existing data could fit into the existing schema the less effort you will ultimately expend in order to ultimately end up with a robust, easily understandable security and personalization system that you did not have to design, write, test and maintain.
Don't get me wrong, I am not saying not to customize the providers. That is the whole point of an abstract factory pattern. But before you take it upon yourself to splice into a database/schema/critical infrastructural system it would behoove you to better understand it.
And once you get to that point you will start to see how simple life can be if you concentrate on learning how to make systems that have thousands of man hours in dev time and countless users every minute of every day work for you the more actual work you will get done on the things that really interest you and your stakeholders.
So - let me suggest that you import your users into the aspnet_db/sqlprovider stack and leverage the facilities provided.
The userId in aspnet_db is a guid and should remain that way for very many reasons. If you need to retain the original integral user identifier - stash it in the mobile pin field for reference.
Membership is where you want to place information that is relevant to security and identification. User name, password, etc.
Profiles is where you want to place volitile meta like names and site preferences.
Anyway - what I am trying to say is that you need to have a better understanding of the database and the providers before you hack it. Start of by understanding how to use it as provided and your experience will be more fruitful.
Good luck.
In my experience, the "ASP.NET membership provider" introduces more complexity than it solves. So I'd go for option 2: a custom user table.
P.S. If anyone has been using the "ASP.NET membership provider" with success, please comment!