I have several different web applications with their own separate databases. All of these different web applications also use a common database for authentication which contains the list of all of my users and the user's name. To keep things simple, let just say my application databases are like a forum and they track user posts; in the tables they will store a userID and some post text.
Now the problem I am having is that some of my team members feel that what we are doing is messy and frictional because it kind of a pain how to get my applications to display a users name next to their posts which is a very common task. First I have to go to the application database and do something like SELECT userID, postText FROM tblPosts then I have to take that userID and go to the user database and get the actual name with SELECT name FROM tblUsers WHERE userID = X. And then merge data from those two queries together to get it out on the page.
I personally don't mind the way we are doing it as I think it's important to just use a single separate user database for data constancy, but some of my team members want to copy over all of the user names into the local application databases and store the user name next to the userID when recording posts so its super simple to get that information back out. In the event a user wants to change their name (a very infrequent event and we only have about 100 users) we should just run an update in the common database as well as all of the application databases.
This seems like a common issue people might have. Can someone please weigh in on the common approaches to dealing with the problem and what we might want to do.
You have a system with a working single-signon scheme (centralized user identity and authentication). That's a huge competitive advantage.
You've built it simply and cleanly. That's even more huge. This kind of thing is very hard to get right, and you have done that.
(If you were to try to build this with some system like LDAP or Active Directory, you'd have a lot of complex code to maintain.)
Don't let your fellow developers sacrifice that advantage for their personal convenience. If you have to synchronize changes to the user database, you will have problems when things get out of sync. It's a when question, not an if question.
By the way, if your user database and website specific databases are on the same MySQL server, you can do stuff like this to integrate the use of the two different databases. That may meet the needs of your developers.
SELECT u.username, d.opname
FROM userdatabase.users u
JOIN website.transaction d ON u.userid = d.userid
But if you do this, you'll make it hard to migrate your various website databases to other server machines in the future.
Related
I am looking for a solution that lets me interconnect several databases.
But let me explain it with the exact example:
I have a main domain (front page for public clients) and four sub-domains (development, management, client, ...) in the clients webhosting.
Each domain has its own database and runs different software (WordPress, dolibarr, sysPass, our own software), but all databases are stored on the same mySQL server.
If a CRUD is made, I want that the other databases also "do" something with that data.
Basically, automation.
For example - a user on development.subdomain.xyz sets a project task to "finished".
When the UPDATE is done to the "development" database, I want an INSERT with parts of that data into the "management" database and an UPDATE towards the "client" database.
I could write up some script that connects to all four databases and does the operations necessary.
But that feels a little hard to maintain if multiple users shall have access to this "logic" system?
I could also use the provided API's and process the data (again in a script form rather than implementing a whole UI).
That feels like adding an unnecessary, extra security concern and again hard to maintain?
If I want to add additional functionality - like sending an Email as well, that would even make it harder for non-coders to interact.
So I found several of these "Low-Code Business Process Management" tools and now I'm at a loss.
Is that what I'm looking for? Can you throw me some tags, keywords or links to guide my search for possible solutions?
I do not even know how to call such a system or search for it - which stops me from progressing.
Thank you for all tips :)
I am trying to build an API first web app that has two parts:
Part A: The Project Management App. This would be built using php/mysql. One of the table in the mysql DB will be the users table where all users information will be stored viz username, password, email etc.
Part B: The online chat App. The users of the project management system will be able to chat among themselves. This will be built using nodejs/mongo. The mongodb DB would store the chat transcripts of each users and so would have a users collection containing the user details. The users collection would contain the same user information that the mysql users table has viz username, password, email etc.
Now, i have a couple of questions in terms of the architecture of this app.
Question 1: Is it at all a wise idea to maintain two different sources to store the user's information? The reason why I wanted to have a replica of the users table in the MongoDB as well is because since there will be too many reads and writes happening in the chat app so its best we use a nosql DB. (Lets assume here that my app will be used heavily going forward)
Question 2: If the answer to Question 1 is "Yes", how do we make sure of data consistency? I have thought of two approaches to achieve this:
Option A: Since we are using the API first approach, so during the registration of a user when the CREATE user api call is made, it will add the user in both mysql and mongodb databases.
Option B: I setup a cron that will sync the data between the mysql users table and the mongodb users collection periodically.
Can someone please throw some light on this and tell me if my approaches are right and that if I am going towards the right direction.
Many thanks
I was looking into how to add a create user account/login to my website, so I could have members join and come back, etc and ended up finding out in order to do that, I'd need to create a new database in my SQL, to store the users credentials, I dont have the option to create any new databases by my webhost. Only the one database is what I can use. Could I just add this to my existing database? Do I really need more than 1 database on SQL for my website? If so, could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website? Im sorry for the few questions, Im really new to all this and so confused and overwhelmed.
You can create multiple tables in same database.just make a table with fields such as user id,password etc. and use it for saving,fetching user details using sql queries.
Could I just add this to my existing database?
Yes, you can tables to the existing database.
Do I really need more than 1 database on SQL for my website?
There are a lot of websites that use just one database. Some websites use connections to multiple databases. What information is stored in which database is frequently the result of factors other than the website. The ability to connect to multiple databases means that a website could use authentication/authorization info from one database, store user profiles and submissions in another, and read information from other sources (for example, historical stock prices, stored in another database.
All of that information could be stored in a single database. Having them as separate databases means that the databases can be managed separately (frequencye of backups, replication to DR site) and makes it easier to share the database across multiple applications. (For example, we would probably want employee payroll and health care information stored in a separate database, with separate access controls.
Could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website?
It may be technically possible to do that, but that's not the way you want to go. That would add another dependency... the website at the web hosting provider would be dependent on having access to another database, which is not being backed up and managed along with your website.
One of my sites is a social networking site running on MySQL. I use postal code and country information to geolocate users using a webservice. This webservice also allows you to download all their many tables of information so that you can access it locally. My site has gotten big enough that I wish to do this now.
My question is, should I create a new database on my site for all of this postal code and country information and all its tables, or should I incorporate those tables into my existing database for my social networking site?
What are the pros/cons either way?
When you're talking about scaling and want to know about other databases like NOSQL, you might find this article interesting: http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html
I'd vote in favor of a separate database if you planned to use the data as read-only and put a web service in front of it to access it. Users would search it based on a small handful of parameters (e.g. address info to get lat/lon data).
I'd say put it in the existing database if you planned to JOIN it with other information in your current schema.
it will live on the same disk probably.
so disk space is not an issue.
if you query the tables in a completely separate manner, then no impact on the existing site.
if you query things together, then easier when all in one database.
overall administration of one database vs 2 is easier.
i think it's a no brainer... they go in one db.
My program is intended for multiple projects (clients) use. I am working w/ PHP and Mysql.
For example, the implementation of the program for a client would include all the tables needed, and a list of users of that client.
Each implementation of the program (for separate and completely different clients) would make use of the same set of tables but separate. For example, there will be a userlist TABLE for client A, and one for client B. But they are not the same table.
Am I going to have a separate database (and as a result, initiate a new set of table for each new DB) for each implementation?
What do I have to lookout for I'm still early on in the programming phase, but would like to prepare for down the road. Still programming for the tables within one DB, but I don't want any surprise down the road.
I am currently hosted on a public hosting company.
You can create one master table where it will store the database name for each client and clients login crediential.
Once they login, according to their client ID, you need to select the database.
For new client registration, you need to create a copy of the database with their client name prefix.
Definitely go with multi tables. It will save you a lot of time in the future if you need to debug/update/delete a single client. Also, if client want a custom fix for something and you decide to make it, than you can hurt your other client's data. Also, you may be need different charset collation.