Through my companies website, our users can make artwork requests. Currently they are just being emailed to a single person.
I have been developing a separate application we'll call it "artwork manager", that will queue these artwork requests for our in house artists, and they will be passed out accordingly.
Our company website database contains the art_request table that this other application needs access to.
The "artwork manager" application only has an artists, art_doc, and awards, tables.
Should I just add these tables to our company website, and connect to that database? Or would it be best to use a separate database for each application? They are both being hosted on the same server.
Don't separate your databases, it will create a lot of confusion on development later. I strongly suggest merge it to one application.
Related
I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.
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.
We currently have an desktop application that is sold to small businesses and used as a server/client model application and we are in the early stages of researching the possibility of adding cloud-based syncing to the program.
Besides the obvious hurdles in transitioning/recoding the networking code of the program itself, there seem to be many additional questions related to the server/database selection, available cloud services, scalability, and more.
For example, currently the non-cloud application simply connects to a specified MySQL database file and then loads/views/updates data. This database can even be stored remotely on a server and accessed from multiple machines, for example:
db=New mySQLCommunityServer
db.host="12.23.56.57"
db.port=3306
db.databaseName="myData"
db.userName="userName"
db.Password="password1"
db.connect
But for a distributed cloud application, it would need to connect to a the same host and SQL database name but with each specific user's login and password and access their specific database and tables. Where would that translate into the code above?
A few questions arise:
Would a new entire database need to be created for each new user account that signs up?
If so, how would changes to table formatting be applied to all user databases. Assuming roughly 500-1000 users signup, having 500-1000 separate databases doesn't make much sense.
Would this be better accomplished using a service such as Amazon Web Services? Even there, it was a bit unclear how the "program user account" would translate onto their services.
Thank you for any feedback!
I have recently been working on a student marketplace website (collegestall.com). It currently has an integrated student housing section which I want to seclude and develop into a separate subsidiary website of the main example.com website.
The problem is that the subsidiary website will need to access some data from the database of the main website (example.com) whilst also having it's own separate tables.
Here are my options
Use two different databases but connect to the main example.com database when needed
Use only one database
Which option is better for scalability etc? The problem with the second option is that if I ever wanted to move the subsidiary website onto a different server to the main website, how will it access the data it needs?