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.
Related
I am designing data base for inventory management system which is used by nearly 10 to 15 companies. This database contains nearly 25 tables.For designing database i'm planning to use shared schema architecture(ie each schema corresponding to a company and these all schemas are to be placed in a single database).
i want to know whether it is reliable to use shared schema architecture.
can any one please tell me is it correct decision to use above mentioned architecture.
Thanks in advance..
If I read your question, you are suggesting that each company has its own schema. This means two things:
If you decide to implement a basic change in the schema (ie not a change that one company requests), then you will have to implement this change in all the schemae.
You will probably have to implement different logic in your front
end program for each company.
Better you should develop one schema for the entire database; each table would have a field called 'CompanyID' which naturally would define to which company each row belongs. This field would be a foreign key to the Companies table.
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
I know the title might be confusing, but it's the best I could came with in order to explain the question.
Background:
I have a domain, a domain has 2 databases: one nosql (Mongodb) and one sql (Postgres); each database have their models. For example if the domain name is "myapp" and the version is "v01" then it will have a database named "myapp_v01" in both the sql and nosql.
Migration - copy database:
When I migrate I usually create a new database named like this "myapp_v02" (notice the 2). Then the migration script will clone tables or will get data from "myapp_v01" alter it somehow and save it to "myapp_v02" in a different way. I don't know if this will be very scalable or how it will be when it will take 1 hour to make the migration?
Migration - copy tables:
I could simply create a new temporary table to make the migration changes (copy from table "cars" to "cars_temp", then drop the "cars" table and change the name of "cars_temp" to "cars").
Migration - alter tables:
This is a little bit more tricky because we have both sql database.
In sql I would need to make the alter schema first and then somehow update each row when needed.
Conclusions:
I think the 3th one is the fastest one but I don't really know what are the best practices here.
Thanks
I'd consider the third the default approach. It has a couple of arguments in favor:
You don't have to touch things you do not change. It just stays where it is like it is.
You can easily do phased changes, like adding a column in v1, starting to fill it with data during the lifetime of version one, possibly in batches, actively using it in v2 and possibly deleting an old column in v3 when you are really sure all the new stuff is working nicely. Sounds cumbersome to do that in the other aproaches.
With large databases copying all the data might be prohibitivly expensive (more thinking about time and I/O than disk space)
UPDATE Answering the additional question in the comment
If you want to merge to columns A and B into a new column C you have various options based on the third approach from your question:
The Safe Way:
- stop the application, so nobody can write to it.
create and fill the column C
possibly remove not null and similar constraints on A and B
deploy and start new version of application which only uses column C.
any time later drop column A and B, possibly only weeks later with the next release.
The quick Way
- stop the application, so nobody can write to it.
create and fill the column C
drop A and B
deploy and start new version of application which only uses column C.
Since you seem to have problems with your application and unused columns, this might be the way to go.
The Way For Legacy Code
- create the column C (note: all apps are still running)
create triggers that keep A,B and C in sync (this can also be done with views and possibly other vendor specific RDBMS features)
deploy and start new version of application which only uses column C.
migrate all other application to only use C
any time later drop column A and B, possibly years later.
This is for cases where you have lots of apps using the db that you can't change all at once.
I have no idea about sequelize in mongoose ... sounds like a fairy tale adventure to me :-)
Im wondering what will be the best way to organize my DB. Let me explain:
Im starting a new "big" project. This big project will be composed by few litle ones. In general the litle projects are not related to each other, they are just features of the big one.
One thing that all the projects have in common is the users that are going to use it.
So my questions are:
Should i create different DB for each one of the litle projects
(currently each project will contain 4-5 tables)
How to deal with the users? Should I create one DB for all the users
or should i
duplicate the users table in every DB? Have in mind that the
information about the users is used a lot in every litle project,
it's NOT only for identification purposes.
Thanks in advance for your advice.
This greatly depends on the database you choose to use.
If these "sub-projects" are designed to work as one coherent unit, then I strongly recommend you keep it all in the same database. One backup, one restore, one unit.
For organizational purposes, if you are using a database which supports it, select a different Schema per project. PostgreSQL and SQL Server are two databases (among others) which support this effortlessly.
In the case of a database like MySQL, I recommend you pick a short prefix for each subproject and prefix all tables accordingly. "P1_Customer" for example.
Shared data would go in it's own schema or prefix, like Global or something like that.
Actually, this was one of the many reasons we switched our main database from MySQL to PostgreSQL. We've been heavy users of both, and I really appreciate the features that PostgreSQL offers. SQL Server, if you are in a windows environment, is a great database IMO as well.
If the little projects are "features of the big one" then I don't see a reason why you wouldn't want just one user table for the main project. The way you setup the question makes this seem true "If there is a user A in little project 1, then there must be a user A in the 'big' project." If that is true, you should likely have the users in the big db instead of doing duplication unless you have more qualifying details.
i think the proper answer is 'it depends'.
Starting your organization down the path of single centralized system is good on many levels. I think in general i would recommend this.
however:
if you are going to have dramatically different development schedules, or dramatically different user experiences with the various sub projects, then you may be better off keeping them separate.
I'd have a look at OpenID or some other single sign-on protocol depending on the nature of your application. OpenID includes a mechanism called "attribute exchange", which allows applications to retrieve profile information from the OpenID provider.
This allows you to create a central user profile repository, with an authentication scheme, and have your individual apps query that repository for profile information.
The question as to how to design your database is hard to answer without more information. In most architectures, "features" within an application tend to be closely linked - "users" are related to "accounts" are related to "organisations" etc.
I'd recommend looking at the foreign key relationships to answer this question. If you have lots of foreign keys, build a single database for all tables. If you have "clusters" of foreign keys, and you want to have a different life cycle for each application (assuming the clusters map neatly to the applications), consider separate databases.
By "life cycle", I mean mostly the development lifecycle - app 1 might deploy weekly, app 2 monthly, app 3 once only and then be frozen.
I have an issue where I'm creating a greenfield web application using ASP.NET MVC to replace a lengthy paper form that manually gets (mostly) entered into an existing SQL Server 2005 database. So the front end is the new part, but I'm working against an existing moderately normalized schema. I can easily add new tables, views, etc. to the schema, but modifying tables is going to be near impossible. There's currently at least 2 existing applications (that I'm aware of) that reference this schema and I've stumbled upon at least a dozen "SELECT * FROM..." statements in each. They exist both in code and in views/triggers/stored procs/etc. That's why modifying existing table schemas is a no-go.
All that being said, the form targets different fields in multiple tables in database. It also has to be dynamic enough to allow the end users to add new questions targeting fields. The end users have a rough idea of the existing database schema so they're savvy enough to know how to pick out tables/fields to be targeted.
I'm have a really rough idea of how I could tackle this, but it seems like complete overkill and will be difficult to write up. I'm hoping somebody might have a simple(r) way of handling this sort of project that I haven't thought of.
If users know DB schema maybe you should go with Dynamic Data project and just create a web app front end of that DB to them. So you would only make the model they need and do the application that will display data from those tables with insert/edit capabilities.
But it's completely different story if they have some additional functionality to it.