Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm working on a side project of mine using rails api. The app is like a project manager which the structure is gonna be different based on the company type. For example a company which is doing production is different with a company that provides services. Does it make sense to use multi db in this case so based on the company type the users are gonna have different interface and structures?
Thanks for your time in advance
It makes sense to use multiple databases when you're reaching the resource limits of a single database in your application. Of course this presumes you have also followed best practices along the way (efficient queries, effective caching strategies, etc.) Rails 6 has support for replicas which allow you to automatically separate your db writes from your db reads based on the HTTP verb. Beyond replicas, Rails 6 supports using a distinct database with its own replica for a custom collection of ActiveRecord models.
For more details I would recommend taking a look at the Rails Guides on Multiple Databases.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 days ago.
Improve this question
Program A is good at collecting data while Program B, in another language, is good at creating REST APIs. Is it possible to connect these two with a single database that A and B will read and write to? Performance for database operations is not really an issue in my case.
Sure this is possible. Databases typically can handle multiple connections from different programs/clients. A database does not really care which language the tool that is making the connection is written in.
Short edit:
Also most databases support "transactions". Which are used to cover that different connected clients do not break consistency of your application data while reading and writing in parallel.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm just starting to get into web development, and I am planning a website.
This website will have users that can edit data. Think of it like a tree:
Theres the organisation (company), then under the organisation there are users. Each user can have multiple "clients", and the user can edit data about the "client" and share that data. The type of data are numbers and text mostly, and possibly some images.
What database paradigm would be best suited to this? I was thinking documents or relational. I want low-cost, but also lots of room for horizontal (and possible vertical) scaling.
Thanks :)
Considering your requirement, Google Cloud SQL will be the best option for you. It provides data manipulation option and horizontal scaling.
Google Cloud SQL is a fully-managed database service that offers high performance, scalability, and convenience. Hosted on Google Cloud Platform, Cloud SQL provides a database infrastructure for applications running anywhere.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to create multiple services, which support an SSO (Single Sign-On) service.
To simplify, a google like services. With a single account you can use all services (and you log in once).
I found many ideas, but I want to have some opinions on how to design these services, and which technologies are the most adequate:
many or one database ??
creating an auth api ??
sharing session ?
using nosql databse or not ?
duplicate user information foreach database ?
separate users tables on a single database ?
node js vs php !!
...
Update
I know this is opinion based (I ask for your opinions), I wish to have different proposition of design patterns.
It's purely theorique, so I can understand how it can be done.
This is totally opinion based, and will likely be closed. But...
Don't write your own auth service. There are many good packages out there, and very few people are really qualified to write authentication and authorization platforms. If you really don't want to use a pre-packaged solution, at least use one of them as a template.
Here is a good list of SSO solutions, pick one or two and give them a try. Many are free and open-source. I have had luck with OpenAM, but many others are also very good.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I would like to build a scalable server with Cocoa that can handle a lot of clients.
I guess this won't be possible on a single server as they have a limit on their network connections or would it be possible? I then thought of a database that is shared between multiple processes (on the same, or a different server) in (nearly) realtime, so when a change in process A is made, processes B,C,D sync so all processes have the same data.
Is this the correct way to do it? Could this be made with CoreData or are there better alternatives? I have actually never heard of Cocoa being used in server systems, so is it a bad idea to write a server in it?
Thanks.
my vote for not use CoreData on server side, because sqlite not feet my criteria to server side DB, not sure that is good for concurrency access and multiple connection.
I'd recommend to use one of the many, many (many) ready-to-use services out there that already built a proven infrastructure that works and scales. It's not a trivial task.
FWIW we're using quickblox.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In my app I use a static database to store all counties and census areas with the states and territories of the US. This gets updated by the government every 10 years. I use it to search within a county but there are multiple counties of the same name so a state or territory has to be picked first then they select the county within. My question is that I currently have that data in an SQLite database, is that the most efficient or should I use core data? Ther are 3600 lines with 4 items on each line. I just want it to be the most efficient way of storing and reading the data. There will be no writing to it. So which should I choose, I'm open to others than the two I mentioned.
for you case:
core data:
more flexible
(+) it's a ORM (a big plus! So you can add methods to your data models or store whole object-trees with one command)
(+) better integrated into XCode
(+) can easy handle migration of the data scheme
(-) performance (in your case, 3600records only one table)
sqlite:
(+)performance
(-)only C bindings (or you need a
framework)
and don't forget, CoreData is another layer on the top of sqlite. So,.. it's not so easy to compare those both things.
Core data is not a database, it's an object model graph, based upon a database which may (or not) be SQLite.
Using CoreData would need to rebuild all your queries in your app. You're using a rather small and static database, which, I guess, is working fine. Why do you want to change ? Does your app experiencing some speed problems (in that case set up an index on your columns)? Whatever your choice may be, I bet you won't notice any improvement from a database to another with such a simple and small database.
You can look at this answer about CoreData.