Data Bases Comparison

Firebase vs MongoDB

• MongoDB is a more robust document database known for high performance and best-in-class security and has several advantages over Firebase. 
• MongoDB can be operated on-premise or in the cloud (using MongoDB Atlas, or self-managed cloud MongoDB),  It was developed by MongoDB Inc. in 2009. MongoDB provides a more secure
• Firebase is a Backend-as-a-Service (Baas). It provides developers with a variety of tools and services to help them develop quality apps, grows their user base, and earn profit. It is built on Google's infrastructure. Firebase is categorized as a NoSQL database program, which stores data in JSON-like documents.
• Firebase is purely a cloud database service.
• Firebase was developed by Google in 2012. It is not much secure compared to MongoDB 
• Both Firebase and MongoDB are modern post-relational databases that allow for flexibility and speed to market, while Firebase is more popular for smaller applications, and MongoDB is popular for big data and high-performance use cases.

SQL vs MongoDB

• SQL databases are used to store structured data while NoSQL databases like MongoDB are used to save unstructured data. 
• MongoDB is used to save unstructured data in JSON format. all individual records are stored as documents which are collections of fields with a dynamic schema. Here, each collection need not have the same set of fields which makes it more flexible than RDBMS. 
•  MongoDB does not support advanced analytics and joins like SQL databases support.
• In SQL Databases, records are stored in rows within a table which limits dynamic classification and storage of hierarchical data. However, SQL Relational data can be matched using common characteristics simplistically which can be beneficial depending upon your use case.
• MongoDB offers faster query processing but with an increased load and system requirements. Without knowing the purpose of use, it is not possible to classify SQL Databases or NoSQL Databases like MongoDB as better or worse than the other. 
• There are various factors that drive the MongoDB vs SQL decision.
• MongoDB isn't meant to replace SQL. It simply fulfills different needs, and MongoDB and an RDBMS can be used in conjunction
• MongoDB does not support advanced analytics and joins like SQL databases support.
• MongoDB is more fast and scalable in comparison to the SQL server. MongoDB doesn't support JOIN and Global transactions but the SQL server supports it. MongoDB supports a big amount of data but the MS SQL server doesn't

Firebase vs SQL

• Firebase uses NoSQL; MySQL uses SQL. Firebase is horizontally scalable; MySQL is vertically scalable. 
• Firebase uses key-value, wide-column, graph, or document stores; MySQL is table-based.
• Firebase has dynamic schemas to facilitate unstructured data; MySQL has predefined schemas

Most used/popular databases by rank

1. MySQL. Rank: 1.
2. PostgreSQL. Rank: 2. 
3. Microsoft SQL Server. Rank: 3. 
4. SQLite. Rank: 4.
5. MongoDB. Rank: 5.
6. Redis. Rank: 6.
7. Oracle. Rank: 8. 
8. Firebase. Rank: 9.

SVN Short Note

 

 image source

SVN Note 

• Install TortoiseSVN https://tortoisesvn.net/ 
• Commit – push code base to SVN
• Update – update repo from SVN
• Repository checkout 
• TortoiseSVN Repo browser 
• Browse to the repository 
• Copy link 
• TortoiseSVN checkout 
• Checkout paste link 
• Revert to a previous revision  
• Revert to update 
• Revert to this revision 
• Update to this revision 
• Show log 
• Double click logs, will show changed codebase files 
• TortoiseSVN Diff 
• This will show changes from the previous revision, current revision, and current working copy 
• Show diff 
• Differences from the latest update
• Use Winmerge tool for code comparison
• Local modifications
• When the local codebase is updated to remote then project versioned files will be ticked in GREEN
• When the local codebase has new modifications then project versioned files will be ticked in RED
• Other notes
• .svn should be in the project directory - these the files used in svn t track the versioned codebase
• if this file is deleted accidentally then take new checkout from the svn
• If need to delete a codebase file in svn then get update delete the file in local then commit to svn
• tick the red color missing files and commit so it will be removed from the svn

Bitbucket - Git Short Note

image source https://www.whitelabeldevelopers.tech/Bitbucket

 Bitbucket - Git Short Note  

• Jira item 

• Create branch 

• Select repo 

• Git clone repo (clone repo to the local) 

•    git pull (update local tree from the remote tree) 

•    git checkout SSAT-3006-unit-test-add-unit-test-to-su  

• Check current branch  

• Open git bash

• git branch 

• Git bash

•   git bash is a git commandline 

• Git GUI 

• Stage Ctrl + T 

• Unstage Ctrl + U 

• Sign off 

• Commit (to the local) 

• Push (to the remote) 

• Pull request 

• Commit and push to Jira branch

• git pull origin develop (this step is to synch local branch with remote develop branch)

• Resolve any merge conflicts

• Stage, sign off, commit and push 

• Goto Jira item  

• Click Create pull request 

• Create a pull request from the current Branch to develop 

• Assign reviewer 

• Switch to another branch  

• git switch <branch> 

• git checkout <branch>

      Resolve Merge conflict  

                     Goto local working branch

                      git pull origin develop 

• Correct the conflict and compile the project 

• Stage, sign off, commit and push 

• Read more https://support.atlassian.com/bitbucket-cloud/docs/resolve-merge-conflicts/

• Git stash and pop 

• git stash can be used for following 

• Save files to a shelve then when need to change to another branch, because Git does not allow to change branches when new modifications are in the codebase (uncommitted codebase) 

• Do the work in new branch commit them 

• Then git switch <branch> to the old branch 

• Then git stash pop to get back stashed codebase  

• git stash can be used to put unwanted codebase to a shelf  

• during a merge conflict 

• Master branch 

• Release branch 

• Develop branch 

• Development branch  

• Master bit bucket best practices

• Create and work on small tasks so chances for impactful merge conflicts are lower. 
• Sync up your feature branch frequently. 
• Commit to a local end of the work, every day 
• git pull develop before start work on every day 
• Merge your feature branches as soon as possible. If they’re done, don’t let them hang in there. 
• Do not branch too deeply. You will be increasing the time to execute each merge and resolve potential conflicts. Means, avoid a situation like this: 

• Structure your branch tree so you minimize the chances of overlapping sibling branches. You should aim to merge along the hierarchy; i.e, merge children into parent instead of 2 sibling branches. 
• Be aware that the more work is planned to be parallelized the more chances to have merge conflicts. 
• If merge conflicts are unavoidable, plan some time ahead to make sure you address them and their potential side-effects properly.