After many years working with SQL databases, it feels unconformable working with a database that doesn't rely on a schema to model the data.
I understand that SQL and NoSQL solutions have their places for different business needs and goals, but I don't have any experience with NoSQL databases.
But since I discovered that Microsoft SQL Server has support to also work with JSON data (https://learn.microsoft.com/en-us/sql/relational-databases/json/json-data-sql-server?view=sql-server-2017), I wonder:
Can I always default to SQL Server for any (new) application I might need to create and use this flexibility of JSON querying when needed?
That would mean I don't have to wrap my head around considering between SQL Server OR MongoDB OR both. I could just use SQL Server always and be good to go.
A similar consideration of mine is about graph-databases. SQL Server vs Neo4j for graph databases.
(https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-architecture?view=sql-server-2017).
Sure SQL Server support for graph is inferior compared to Neo4j which is specialized for that task, but it seems that Microsoft is trying to create a one-for-all database solution that every project could rely on.
Now a days mostly all database providing the datatype of any field in a table as json type.
But relational database is not providing the solutions as nosql database.
After reading some answers on different websites I am confused now. So, it would be helpful to mention the key difference between DBMS and RDBMS and any relation between them.
Since this question become popular on Stack Overflow, I am posting an answer which answers this question for me. I found this answer on udemy website. Hope this will help future users and newbies searching for a good answer on this topic.
Key Difference between DBMS and RDBMS:
The key difference is that RDBMS (relational database management system) applications store data in a tabular form, while DBMS applications store data as files.
Does that mean there are no tables in a DBMS?
There can be, but there will be no “relation” between the tables, like in a RDBMS. In DBMS, data is generally stored in either a hierarchical form or a navigational form. This means that a single data unit will have one parent node and zero, one or more children nodes. It may even be stored in a graph form, which can be seen in the network model.
In a RDBMS, the tables will have an identifier called primary key. Data values will be stored in the form of tables. The relationships between these data values will be stored in the form of a table as well. Every value stored in the relational database is accessible. This value can be updated by the system. The data in this system is also physically and logically independent.
You can say that a RDBMS is an extension of a DBMS, even if there are many differences between the two. Most software products in the market today are both DBMS and RDBMS compliant. Essentially, they can maintain databases in a (relational) tabular form as well as a file form, or both. This means that today a RDBMS application is a DBMS application, and vice versa. However, there are still major differences between a relational database system for storing data and a plain database system.
Every RDBMS is a DBMS, but the opposite is not true: RDBMS is a DBMS which is based on the relational model, but not every DBMS must be relational.
However, since RDBMS are most common, sometimes the term DBMS is used to denote a DBMS which is NOT relational. It depends on the context.
DBMS : Data Base Management System
..... for storage of data and efficient retrieval of data.
Eg: Foxpro
1)A DBMS has to be persistent (it should be accessible when
the program created the data donot exist or even the
application that created the data restarted).
2) DBMS has to provide some uniform methods independent of a
specific application for accessing the information that is
stored.
3)DBMS does not impose any constraints or security with
regard to data manipulation. It is user or the programmer
responsibility to ensure the ACID PROPERTY of the database
4)In DBMS Normalization process will not be present
5)In dbms no relationship concept
6)It supports Single User only
7)It treats Data as Files internally
8)It supports 3 rules of E.F.CODD out off 12 rules
9)It requires low Software and Hardware Requirements.
FoxPro, IMS are Examples
RDBMS: Relational Data Base Management System
.....the database which is used by relations(tables) to
acquire information retrieval
Eg: oracle, SQL..,
1)RDBMS is based on relational model, in which data is
represented in the form of relations, with enforced
relationships between the tables.
2)RDBMS defines the integrity constraint for the purpose of
holding ACID PROPERTY.
3)In RDBMS, normalization process will be present to check
the database table cosistency
4)RDBMS helps in recovery of the database in case of loss of
data
5)It is used to establish the relationship concept between two database objects, i.e, tables
6)It supports multiple users
7)It treats data as Tables internally
8)It supports minimum 6 rules of E.F.CODD
9)It requires High software and hardware
From Wikipedia,
A database management system (DBMS) is a computer software application that interacts with the user, other applications, and the database itself to capture and analyze data. A general-purpose DBMS is designed to allow the definition, creation, querying, update, and administration of databases.
There are different types of DBMS products: relational, network and hierarchical. The most widely commonly used type of DBMS today is the Relational Database Management Systems (RDBMS)
DBMS:
A DBMS is a storage area that persist the data in files.
There are limitations to store records in a single database file.
DBMS allows the relations to be established between 2 files.
Data is stored in flat files with metadata.
DBMS does not support client / server architecture.
DBMS does not follow normalization. Only single user can access the data.
DBMS does not impose integrity constraints.
ACID properties of database must be implemented by the user or the developer
RDBMS:
RDBMS stores the data in tabular form.
It has additional condition for supporting tabular structure or data that enforces relationships among tables.
RDBMS supports client/server architecture.
RDBMS follows normalization.
RDBMS allows simultaneous access of users to data tables.
RDBMS imposes integrity constraints.
ACID properties of the database are defined in the integrity constraints.
Have a look at this article for more details.
A DBMS is used for storage of data in files. In DBMS relationships can be established between two files. Data is stored in flat files with metadata whereas RDBMS stores the data in tabular form with additional condition of data that enforces relationships among the tables. Unlike RDBMS, DBMS does not support client server architecture. RDBMS imposes integrity constraints and also follows normalization which is not supported in DBMS.
DBMS is the software program that is used to manage all the database that are stored on the network or system hard disk. whereas RDBMS is the database system in which the relationship among different tables are maintained.
DBMS: is a software system that allows Defining, Creation, Querying, Update, and Administration of data stored in data files.
Features:
Normal book keeping system, Flat files, MS Excel, FoxPRO, XML, etc.
Less or No provision for: Constraints, Security, ACID rules, users, etc.
RDBMS: is a DBMS that is based on Relational model that stores data in tabular form.
SQL Server, Sybase, Oracle, MySQL, IBM DB2, MS Access, etc.
Features:
Database, with Tables having relations maintained by FK
DDL, DML
Data Integrity & ACID rules
Multiple User Access
Backup & Restore
Database Administration
There are other database systems, such as document stores, key value stores, columnar stores, object oriented databases. These are databases too but they are not based on relations (relational theory) ie they are not relational database systems.
So there are lot of differences. Database management system is the name for all databases.
DBMS stands for "Database Management Systems" it includes all Databases. RDBMS are a special Type of DMBS . R in RDBMS implies that the database uses the Relational model. a collection of related tables in the relational model makes up a database.DBMS is used for simple and small application while RDBMS is used for applications with a huge database.DBMS are for smaller organizations where security is not concerned(i.e. DBMS does not impose any constraints) while RDBMS is quitely opposite( RDBMS define the integrity constraint for the purpose of holding ACID PROPERTY).
I'm new to the whole backend scene, and I'm trying to find what kind of database is the best for me, and I need to get what documents are. Are documents in NoSQL databases what a table is for a SQL database?
Only specific NoSQL database engines store information using documents and they're named NoSQL document oriented database engines. One of the most famous NoSQL document oriented database engines is MongoDB. They're also other NoSQL engines that store data in a different way, like Cassandra using a key-value structure.
Are documents in NoSQL databases what a table is for a SQL database?
Considering the NoSQL document oriented databases, the documents are much similar to rows of a table of a SQL database. A table of SQL database, instead, is similar to a collection of documents.
There are anyway a lot of differences between them.
For example:
In a SQL database, you have to specify a schema for your table and it's not very easy and recommended to change it, because it ensures the consistency of your data and lets you perform multiple checks (using JOINS, for example) on your data considering different tables.
In a NoSQL database, there's no schema to specify for a collection. This makes easy to store a lot of information without any problem. But what if you have to perform a JOIN to check the data stored in different collections? You can't, because there's no schema defined and no relationships to define between the collections.
I'm trying to find what kind of database is the best for me
It depends on what you want to do with each DBMS. If you want to store a lot of information without caring about joins, relationships between tables, atomicity of operations and so on, use a NoSQL database engine. Otherwise, use a SQL database engine.
Not every NoSQL database even has documents. It's just a small subset of NoSQL databases: The document-oriented databases. In these databases, multiple documents are in one collection. Documents and collection are roughly equivalent to row and table in a relational database.
It's recently fallen upon the shoulders of another developer and I to pull information from a database spanning some 669 tables with no useful documentation or accessible experts/DBAs of the database. We're not even exactly sure what all information is locked away in the tables that we can pull from to create our--effectively--reports.
Is there any tool or method of generating a diagram (or any other way) to visualize the information to speed up the process?
I was thinking about a generic SQL tool, but the specific database technology is Sybase.
I have been using Sybase Powerdesigner for reverse-engineering database schemas some years ago. I used it to generate a database diagram of the tables with foreign keys to show the relation between the tables. It supports other databases than Sybase too.
is there a windows xp utility to make a database such that its support by sql server, oracle, and other db management systems.
the database schema is very huge so i would like to know what to use to make it so its protable from sql server to oracle if future demands that change?
In short, what you seek is nearly impossible to do successfully. Every database product has enough quirks that building such database would not perform well and would be too limiting in terms of the features you were able to use. I.e, you have to play the game of lowest common denominator with respect to features that all products implement you want to support. A far better solution is to abstract the data layer into its own library accessed via interfaces so that you can swap out your data layer. ORMs, as Rafael E. Belliard suggested, makes this simpler but it can also be done manually.
I would recommend building your database using an ORM like Hibernate for Java (or NHibernate for .NET). This would allow you to seamlessly transition from one database type to the other with little to no issues. They would allow you to logically create the database schema without a specific database in mind, which you could then move from one database to the other.
I have created applications which change from SQL Server to MySQL to Oracle to MS Access to SQLite easily (clients love that flexibility).
However, you would need to know your way around programming...