I have been asked to build a SpringBoot POC based on a relationship data set.
For context purposes you can consider an HR system data set.
If chose to build a monolithic app, I can use just SQL database.
If I use microservices patterns, I would need to use Sql and NoSql databases.
Is there a real world scenario where I would split the data between the 2 databases?
Like separation of concerns?
Is there a scenario where one would choose to use 2 databases?
To me it doesn't make any sense, but I might not be experienced enough to have had a scenario like this.
Related
We're looking for the best setup to distribute databases for large databases. We would like to have more databases in multiple computers and to have every database tables which we're using in the particular part of the globe, then we would like to have a common table set which we would like to synchronize between the database nodes. We would like to extend a large platform but it's very hard to implement the functionality which will choose which connection string we need to use. That's why we started to have research on this and seems that DBMS may have this functionality.
Can you suggest some material/documentation/tutorial we could use? We're using SQL server.
Thanks in advance!
I am starting developing a new application for blogs in .net mvc. I am working on relational databases (Sql Server) from past 3+ years, these days i am seeing many articles on No Sql databases too and many articles says that nosql/graphdb is a future so i just want to know which database will be better for a blog kind of application relational or nosql?
I want to go with nosql for learning purpose but there are too many nosql databases like- cassandra, couch, mongo, raven, hbase, neo4j etc so please suggest which db i should choose for blog app-
Relational or No Sql
If no Sql then which No Sql
Hoping for some positive responses.
Thanks.
Basically use SQL or noSQL approach depends on such factors as how your data model (I mean your tables in SQL or lists in no SQL) changes and what will you do with it when you have lots of data.
If you data model pretty much known and changes not often, plus you have really difficult logic to work with it (and validate ofcourse) than I usually use SQL approach, becouse it's easier to keep your data consistency.
The next problem that you faces is huge amount of data. With SQL approach you have to build DWH (data warehouse) if you want to query your data fast. With noSQL approach in theory you can easily spread your data of different servers.
About blog - you definatly don't know right now what kind of model you will have in the end. And you wouldn't create tricky reports i gess. So it's ok to use noSQL model.
About your question what noSQL DB select i recommend to look at brightstardb becouse you can map your model with EF and it will be easier to develop. Another noSQL db that you can look at is Azure DocumentDB becouse it's MS approach to noSQL, but it available only in Azure right now and it has no stand alone version.
I have been using mongo nosql for smaller web applications. Mongo nosql would work really well for such an application.
Easy to connect to, and easy to get into since its object related.
Just my opinion.
I'm developing an ASP.NET MVC 4 web application hosted on IIS which will be using multiple databases on a single SQL Server 2014 instance (each database for a different company). The web application will be used for analysing and summing large amounts of business data.
What is the best practice in this kind of situation? Will there be performance issues if only one web application and pool is used with multiple databases? One database may have 1-20 users.
Which one would be a better choice, A or B?
A) 1 web application and 10 databases
B) 10 web applications and 10 databases
Your question doesn't belong to MVC at all.
If you have large amounts of data and you worry about performance, then you should think about how to store and query data at the database level. And you may interested in this kind of questions:
What provider use to query data? (pure ADO.NET or an ORM like Linq-to-SQL or EF)
Should I have all databases in one SQL Server instance, or can I use linked servers or even union data on web server side?
Should I have my databases files on different hard drives?
Answering these questions:
ADO.NET is always faster than ORMs just because they all use ADO.NET at their core. But it's harder to maintain ADO.NET queries in future
Linked servers are slower especially if you have your database on different machines (you will transfer your data by net and it is not fast if the is a large amount of data)
In the performance way it's better when your database files stored on different hard drives
Answer to your question now will be obvious, I think :)
Create one web application.
Our IT manager is asking my help on deciding on which would be the best to save the data. Is it in sharepoint or sql server.
On my side I don't know much about saving data on sharepoint server, how does it work, how fast, how secured, etc. I even have a doubt if sharepoint is capable of complex database design. As far as I know, sharepoint is not a database server that's why I have this doubts.
So obviously I would say Sql Server would be my prefered storage and also because Sql server is known to me for a long time already. Considering my 3 weeks exposure on sharepoint vs. 7 years on Sql Server. I don't have the enough experience to witness the strength of Sharepoint for me to decide on what to do. So to be fair on sharepoint I would like to ask you guys out there who are more experienced on this.
My questions:
1.) Does sharepoint have the ability to store data?
2.) If sharepoint can store data, what are the pros and cons?
3.) Can it cover a complex design such as relational database design like sql server does?
4.) If you where to develop a sharepoint project, would you choose sql server as the backend?
Thanks in advance!
It obviously depends on the application, and complexity of it, who the client or audience is, and how you want to deploy it.
Here are my answers to your questions:
1. Yes
2. Pros:
It provides a UI for updating data.
Cons:
Creating relational structures will be complicated.
Think custom lookup lists, associated with other custom lists.
3. Yes, but I wouldn't try it.
4. SQL Server, but this depends on the project and
isn't an entirely technical decision.
Personally, I think given your skillset, you should use SQL Server, if your manager has said it's up to you.
SharePoint itself is built on top SQL Server and ASP.NET.
Yes. You can create a custom list (basically similar to table structure), you can store document along with its metadata. You can store web pages if you are using it as your publishing (CMS) platform.
It's not supposed be a relational engine like SQL Server. Pro: versioning, workflow, for most cases, UI is there to support data input / editing. Con: Limitation of the UI w/ large amount of data.
To some degree you can relate one list to another field in a different list / document metadata.
See what I said before point 1.
SharePoint offers its own database layer built on top of SQL Server.
A complex object model is provided, and the SQL language API not available.
Acsess is by API, REST, and UI List Webparts with views; NOT SQL and the database is not accessible except through interfaces.
Deep inside data stored in Entity-Attribute-Value triples (specifically: site, web, list, item, state, field, value) such that each value goes into its own record. This is strickly non-tablular.
Maintains a dynamic end-user populated Metadata dictionary.
As a non-relational layer above a DB is offers inheritance, multi-type list, hierarchies, taxonomies, versioning, check in/out and other advanced features missing from a relational model.
Documents may be attached to a list.
Extensive use of GUIDS for identifiers, but this causes problems when moving partial related data between systems.
No referential integrity.
No joining of database tables or lists.
Filtering is more limited than in SQL.
No concept of a schema.
Parts of SharePoint break when restoring from a backup or when published to a separate site.
Rolling new features and data from development to production is problematic and sometimes breaks.
Hope this helps.
Sharepoint is obviously not a Database Server but somehow it works on some ways.
1.)Yes
2.)You can but not as complicated as Sql Server does.
Pros: It's the interfaces the gives sharepoint the edge, UI grants the user a friendlier way of inputting data.
Cons:Just like what I've said complicated database design is not easy to do.
3.) 100% Yes
4.) I would prefer Sharepoint if the application doesn't need complex design on data. Definitely Sql Server for enterprise type of application.
I want to store code similar to how jsfiddle stores code. I currently use Postgres for my main database but I'm wondering if it's more ideal to be using a NoSQL database?
Code snippets for now will have just one author, but in the future there may be multiple authors and I want the ability for reverting as well.
I know there are key/value databases and document-oriented databases. Which specific noSQL db would suite my needs? Or should I still stick with my Postgres db?
FYI:
I'm using django
The users will be permanently stored in postgres ( I'm using openID )
You can't choose a non-relational data strategy without defining what you want to do with your data.
Relational database design comes from rules of normalization, which you can apply once you know your data alone. But non-relational database design depends on your queries more than your data.
But without knowing anything about your application, my first recommendation would be to stick with PostgreSQL. Store your code snippets in text blobs, and meta-data about the code (authorship, date, language, project, etc.) in additional columns alongside the text blob. Also you can consider using GIST indexes to allow for flexible searching.
You might also consider Apache Solr, which is technically similar to a document-oriented DBMS, though it is usually presented as a fulltext search engine.
As for NoSQL databases, the only ones I'm familiar with are XML (doesn't scale well and has bad concurrency), and local databases such as Paradox, dBase, FoxProx and Access. I would not recommend any of these.
I think that the idea that it's a NoSQL database should be a smaller factor in your decision. Consider these things instead.
Redundancy. Can you run it on two servers at the same time or does it support failover? (SQL Server, Interbase, Firebird)
Concurrency. Will you host this app on the web? How will it handle 10 concurrent operations? (PostGres, MySql, Interbase, Firebird)
Speed. How long is acceptable for a lookup or post?
Embeddability. Is this a desktop application? An embedded database can make things easier. (Local databases such as Paradox, dBase, FoxPro, Access, Interbase, Firebird or SQLite)
Portability. Desktop apps may run on Mac, Linux, Windows. (SQLite)
Sounds like a relatively uncomplicated application which could be implemented in a traditional relational database or a NoSQL without too many problems.
However if you're keeping the userbase info in PostgreSQL, it would seem simplest to just stick with that as a single storage method. Using both an SQL database and a NoSQL adds complexity, makes joining across the datasets hard (so eg. you couldn't make a query to do something like ‘list users along with their most recent document’), and makes it impossible to ensure consistency between the two datasets.
What do you get for this trouble? You want versioning. CouchDB will give you revision control, but it's questionable whether you should be using that for UI-level versioning (eg because compacting the database will lose your old versions).