Some architectures keep data in an SQL database and sync it with Elasticsearch to support some advanced search options that Elasticsearch is good at, but if they do that, what is the reason to keep the data in the SQL database? After all, you can create, read, update and delete in in ES also.
Thanks.
I can see reasons for keeping it in SQL if your architecture was built around for example you might be using an MVC framework like Laravel or Django that plays nice with sql and the relational db architecture.
Related
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 am working with industrial equipment that inserts some text data into a SQL Server 2008 database every time it cycles (about every 25 seconds). I am looking to forward that data to a mongo database in real time to use with an internal Meteor application.
Would there be any obvious starting point? The closest answer I have found is at: https://github.com/awatson1978/meteor-cookbook/blob/master/cookbook/datalayer.md
Q: Well, how am I suppose to use the data in my SQL database then?
Through REST interfaces and/or exposing the SQL database as a JSON stream. We put the ORM outside of Meteor. So, the trick is to move your data from your SQL database into Meteor's Mongo database, and have Mongo act as an object store or caching layer.
Apologies, if it is something obvious.
You need to use Mongo, but as simple repository for your MySql database.
This maintains all Meteor's characteristics and uses Mongo as a temporal repository for your MySql or PostgreSql databases.
A brilliant attempt to that is mysql-shadow by #perak (https://github.com/perak/mysql-shadow). It does what it says, keeps Mongo synchronized both ways with MySql and let's you work your data in MySql.
The bad news is that the developer will not continue maintaining it, but what is done is enough to work with simple scenarios where you don't have complex triggers that update other tables or stuff like that.
This works with MySql of course, but if you look at the code the MS SQL implementation is not hard.
For a full featured synchronization you can use SymmetricsDS (http://www.symmetricds.org), a very well tested database replicator. This involves setting up a new java server, of course, but is by far the best way to be sure that you will be able to convert your Mongo database in a simple repository of your real MySql, PostgreSQL, SQL Server , Informix database. I have to check it myself yet.
For now MySQL Shadow seems like a good enough solution.
One advantage of this approach is that you can still use all standard Meteor features, packages, meteor deployment and so on. You don´t have to do anything but set up the synch mechanism, and you are not breaking anything.
Also, if someday the Meteor team uses some of the dollars raised in SQL integration, your app is more likely to work as is.
when using a specific database such as sql server,do we have to install and configure odbc?
and my other question is why cant thrift/avro/rest/protobuf be used with rdbms,they are services,why are they just used with nosql dbs?
I am reading professional nosql book,and there is a list of different nosql db access methods,and they are listed as nosql db access methods,but when I googled them I saw they are services for serializing datas and so on(each of them is for sth).
thanks in advance.
These are multiple questions here.
(1) No, SQL Server is accessed best via the SQL Native Client, ADO/MDAC/OLE-DB. Performance-wise ODBC is not recommended at all, although it still may be the most viable option in certain cases.
(2) Thrift is only an RPC-mechanism, which has nothing to do with DB in General. This is a completely different aspect. However, Thrift can of course be used, and in fact it is actually used by the NoSQL database Apache Cassandra
I'd recommend to first find out what kind of DB is most suitable for your use case: It may be a typical SQL database, or it may be a classical ISAM or even something like Cassandra, CouchDB or MongoDB. Once you know that, you'll surely find out how to conect with the DB of your choice - or just ask another question :-).
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.
We have a SharePoint 2007 site. It is supported by two back-end databases - one hosted on SQL Server, another on an open-source RDBMS. We issue CAML queries to retrieve data from SQL Server, and ADO.NET queries to retrieve data from the other server. Our architect says we would be better off if we used the same approach (namely, CAML) to get data from the both databases.
Is it possible to use CAML queries to retrieve data from any RDBMS other than SQL Server?
If so, please suggest any web resources, docs, anything you find appropriate.
CAML (at least that part used for SPList.GetItems queries) seems to be quite simple, so translating it into valid SQL statements should not be too complex. Which means, you could create a "translator module" and issue your queries against it. For instance, you can follow guidelines published in the article "[Implementing a .Net Framework Data Provider](http://msdn.microsoft.com/en-us/magazine/aa720164(VS.71).aspx)".