Is there any tools or good formats to keep a documentation of NoSQL database?
The use cases are:
Keep track of the current db collections and their properties defined in schema
Having detailed description of what each properties means
Maintain a change log
Design the collection schemas before implementing
Help building new projects by new teams when they're using the same db
All these can be done using Google doc, confluence or other documentation tools. I want it know if there's any standard practises to make this documentation and if there are any existing tool out there to help with this.
Related
How can you migrate your data from one graph database (Neo4j, Tiger Graph etc.) to another?
Background:
I have to decide between the standards of the W3C (RDF (S), OWL) and
Databases for property graphs (Neo4j, TigerGraph etc.).
I know that all "triple stores" that support the W3C standard also make it possible to simply "pull out" the data
and import it into another triple store.
For relational databases there is also the standard SQL (and dialects),
so that with a little effort you can get the data from one relational database to another.
But I can't think of such a solution for graph databases.
As someone already mentioned for the property graphs there is no defined standard as of now. There are efforts going to build such standards called GQL https://www.gqlstandards.org/
However, for importing data from RDF to property graphs. Tigergraph and neo4j provides option to load your rdf data to the respective platforms. This might not provide complete switch over capabilities from RDF to Property graph but can help with solutions for certain scenarios.
For interchanging data between property graphs you might have to re-create schema when you switch platforms. For data loading most of property graph dbs provide option to load using csv's.
I'm beginning to pursue my first online project that I am planning will need to scale as such I have opted for a NoSQL DB. Some reading into this and modeling of what my queries would look like and there are two databases I am considering. Cassandra seems like the right choice for item lookups by keyword but MongoDB sounds like the right choice for initially entering the data in as it can retain the account structure in document form.
This split decision has left me wondering: Are there any major companies that use multiple database types for storage of different items as in using both Cassandra and Mongo together?
I would think scaling up would be more difficult but are the added benefits (if there are any) worth the trouble? I'm not the expert on this. I'm hoping you are. Thanks in advance for sharing your experience.
Cassandra can handle both use cases so you can use the same database for your purposes.
Stargate (https://stargate.io/) is an open-source API platform which provides a data gateway to Cassandra with REST API, GraphQL API, Document API and even native CQL access.
The Document API lets you save and search schemaless JSON documents to/from Cassandra directly from your app.
You can try it out for free on Astra with no credit card required. In just a few clicks, you'll be able to launch a Cassandra cluster with Stargate pre-configured so you can use the Document API straight out-of-the box and build a proof-of-concept app immediately without having to worry about downloading/installing/configuring a Cassandra cluster.
There are even sample apps you can access straight from the Astra dashboard so you can see Stargate in action. For more info, see Using the Document API on Astra. Cheers!
Using multiple database technologies in the same project is somewhat common nowadays and it is called "Polyglot persistence".
Many people use this method to take advantage of multiple systems - and as you mentioned Cassandra is right for somethings and something else (maybe MongoDB) is best for something else, so using a combination can give the advantage of both worlds.
Scaling, Replication, Support can be more costly when you use multiple technologies because you need expertise in both to support.
So if you really have use cases where Cassandra wont be a good choice and you have some primary use cases where Cassandra is the best choice then yes, going with two databases can be the best option provided you are ready to take the trouble of supporting two systems.
If I choose RavenDB for a fairly standard CMS-like web application, what do I lose compared to SQL Server?
EDIT: There is a word "benefits" in the title which is a little controversial term. Maybe I should have said something like "possibilities" or "features", hope it's clear what I'm after.
A few things that come to mind (but I'm new to RavenDB so this is just a few suggestions, some may be wrong, I hope someone would provide a more complete and accurate list):
Quick but customizable administrative interface using ASP.NET Dynamic Data (there is some built-in Silverlight admin application but I'm quite sure that it wouldn't replace a full-fledged admin section in my case)
Possibly some querying capabilities? Or can Raven indexes replace virtually every SQL query I might think of?
Entity Framework integration (I know some people hate EF but I think that being an EF provider means that you can easily publish the data as OData, use EF code-first etc., right?)
Azure deployment (not true according to comments)
Myriad of SQL querying / management tools
A more complete / accurate list would be greatly appreciated.
(Note: I'm not saying that I will need all (or any) of those, I'd just like to understand what's going to be unavailable if I choose RavenDB. Also, please don't discuss RavenDB strengths, I am aware of them and they are easily digestible from the official website.)
You may want to look # these 2 recent blog posts by Ayende (RavenDB creator) on when you should use RavenDB and when you shouldn't.
When should you use ravendb
When should you not use ravendb
Beyond the technology, you should consider your team members as RavenDB is an adjustment in thinking for those of us who have backgrounds in RDBMS. What type of stretch will this be for those involved? Will your users expect reports and what will the say when you tell them that you did not consider answering the questions that they want answered when you create the indexes for the document database? While you get a big boost in productivity when designing and implementing your domain, document databases are different than SQL.
Quick but customizable administrative interface using ASP.NET Dynamic
Data (there is some built-in Silverlight admin application but I'm
quite sure that it wouldn't replace a full-fledged admin section in my
case)
ASP.NET MVC supports scaffolding based on POCOs since second version. But it's not so quick'n'dirty solution.
Possibly some querying capabilities? Or can Raven indexes replace
virtually every SQL query I might think of?
You should to think about your queries first. Raven DB is not reporting database.
Entity Framework integration (I know some people hate EF but I think
that being an EF provider means that you can easily publish the data
as OData, use EF code-first etc., right?)
You are so focused on tools. Code First is the way how you work with document databases. Why you need OData? RavenDB has REST API out of the box.
WCF RIA Services (Silverlight).
You'll need to do all that WCF plumbing work.
I want to use JDO for Datastore....Please provide any materials or tutorials other than google documents....
I need to know....How to create a database in Datastore and add Multible tables in that database and add properties and corresponding values to the properties.....
How to do this in Datastore....
Please help me....
The Storing Data section of the App Engine docs covers this in extensive detail. You should definitely read it thoroughly before looking elsewhere, as it covers all the basics. It also describes the structure of the datastore - including the fact that the datastore does not have a fixed schema - so it has no tables, and no fixed columns.
Requirements for archival type software
1. Data/Image/possibly video.... upload/search/retrevial/edit from web.
2. Easily implemented user defined Custom Fields
3. Easy backup.
4. Low cost ... either opensource or very low cost
I am a very novice programmer. My primary goal is to manage a collection and publish it to the web.
Options
A. Open source software such as collective access
Problems: Custom fields not supported. Continued support? Portablity of
database?
B. Use Microsoft Access and then use MVC or other development platforms to eventually
publish to the web.
Problems:Difficult to integrate to web?
C. Design my own MVC database application.
Problems:Difficult for novice programmer? Custom Fields and Upload of various data
formats difficult to implement?
Sounds like you are looking for a Digital Assets Management system. I found ResourceSpace (http://www.resourcespace.org/) and Razuna (http://www.razuna.org/) very useful for similar projects - both fall into your A category.
Requirements for archival type
software 1. Data/Image/possibly
video.... upload/search/retrevial/edit
from web. 2. Easily implemented user
defined Custom Fields 3. Easy backup.
4. Low cost ... either opensource or very low cost
Hi there,
As mentioned here before, but Razuna will satisfy your requirements quite well.
It can manage images, documents, videos and audios. It will share folderd and collections on the web with access permissions and will allow you to search among the different kind of assets as well.
Moreover, it can handle metadata of all this asset. It will not only read metadata, but also WRITE metadata, also. Furthermore, you can set the custom fields for each asset type and users will have a web interface to work with.
Razuna supports different databases (H2, MySQL, MS SQL and Oracle (soon DB2)) and let's you migrate from one db to another with ease (backup / restore option).
Best of it all: It is available under a open source license for you to deploy and enjoy today. You can get it at http://razuna.org.
Kind Regards,
Nitai
PS: I'm the main developer and founder of Razuna.