when we say rdbms that means it may be oracle, my sql, ms access etc.. But for dbms what are the examples. Is there any example or it just the concept?.
A DBMS is a database management system. There are two crucial features a DBMS must provide:
storing data
standardised access to the data
The second function is the crucial one. I can connect to a DBMS with a generic client (e.g. through JDBC and discover the organisation of the data stored therein. I can do this because a real DBMS maintains metadata - data about the date it stores - in a data dictionary or an INFORMATION_SCHEMA.
So we can see that flat files do not constitute a DBMS. They handle the first part, persistence, easily enough, but they fail on the second: only the application (or person) which wrote the data can interpret the data structure. This means that spreadsheets don't count as a DBMS either (although a case can be made for XML files).
An RDBMS is a particular type of DBMS which implements Codd's famous Twelve Rules. Many database theoreticians would arge that the products you list (Oracle, MySQL, MS Access) are examples of SQL DBMS rather than RDBMS because they fail to satisfy two or more of Codd's rules: they all fail Rule 0 and then at least one other rule.
There are other types of DBMS. There is the hierarchical form, of which the most venerable is MUMPS . There are object-oriented OODBMS, such as Intersystems Cache. There are network (graph) DBMS e.g. IDMS and Neo4J. And thene there's the whole raft of other NoSQL databases most of which probably qualify as DBMSes.
dbms = database management system
rdbms = relational database management system
So every rdbms is also a dbms.
You might want to name Gemstone, an OODBMS, or Cache, a hierarchical one.
Database management system has a list of links to various types of DBMSs which then link to lists of examples for that type, for example a list of Object DBMSs
Related
We are involved in quite a new development in which we are remaking our current web shop platform.
In the current platform we do not use EF6 neither other ORM but store procedures to access to the db, but in the new building is what we do.
We have a doubt regarding database design of the new platform. In the current platform we use several different databases depending on the content of them.
For example, we have dedicated databases to store information for products catalogs other dedicated db for handling orders.
Currently all data access is done through stored procedures, so we have no problem with the links between different databases.
The problem appears to us now when we have started to use EF6. In this case each DB is associated with a context and it is not possible to know data from one context to another
unless we implement directly in the source code these relationships using various contexts. It looks like these means we will lose the power of EF6.
The questions we have are:
Is it a bad design maintaining different databases for the same application using EF6?
in case this is a poor design and choosing for a single database, is the performance going to be optimum even driving hundreds of tables (almost 1000) with several TBytes of information?
in the other hand, in the case of opting for the design in which several bbdd appear (it would be much better in our case), what is the best way to handle them EF6?
Thank you very much for your help!
First of all EF is not written to be cross database. You can't write cross database (cross context) queries, lazy load does not work and so on.
This is a big limitation in your case.
EF could work with several schema (actually I don't use it and I don't like it but is just my opinion).
You can use your stored procedures with EF but as I understand you are thinking to stop to use them.
In my experience I wrote several applications with more than one database but the use of the different databases was very limited. In this cases I use cross database views (i.e. one database per company and some common tables with views in company databases that selects data in common tables). In your case, if the tables are sharded everywhere I don't think this is a way you can choose.
So, in my opinion you could change the approach.
If you have backups problems you could shard the huge tables (I think facts tables and tables with pictures) and create cross database views. BTW, also, cross database referential integrity is not supported in SQL Server so you need to write triggers to check it.
If you need to split different application functions (i.e. WMS, CRM and so on) you can use namespaces without bothering about how tables are stored in the DB.
How to design the relational database layout to capture structured logging?
Usecase 1
The output of sensors should be logged. Data: temperature and sensor-id.
Usecase 2
The duration of web requests should be logged. One entry for every request. Data: URL and duration
Common data
The two usecases are just examples. There could be much more. Each log entry should have a timestamp and a source-host column
Relational
Please don't tell my to use noSQL. This particular question is about a relational database layout. :-)
Our preferred database is PostgreSQL, but this should not matter here.
In similar case I used, and suggest, separate tables.
If you can use postgresql, you can take advantage from inheritance.
In your case you can use a master_table for common_data and inherit the others table.
You wrote you prefer postgresql, so I assume you know, but, just in case: http://www.postgresql.org/docs/9.4/static/tutorial-inheritance.html
Using this you will take advantage of specific indexes in your data.
Another way is to use a single table with common data and other data in a json or hstore data, but this is close to have a nosql db. And no real advantages in this case, except faster coding.
Although this question fancies PostgreSQL, it is still a general DB question.
I have always been curious about the term schema as it relates to databases. Recently, we switched over to using PostgreSQL, where that term has actual significance to the underlying database structure.
In PostgreSQL-land, the decentralized structure is as follows:
DB Server (`some-server.com:5432`)
>> Database (`fizz`)
>> Schema (`buzz`)
>> Table (`foo`)
Thus, the FQDN for table [foo] is fizz.buzz.foo.
I understand that a "database" is a logical grouping of tables. For instance, an organization might have a "domain" database where all POJOs/VOs are persisted, an "orders" database where all sales-related info is stored, and a "logging" databases where all log messages get sent for future analysis, etc.
The introduction of this "schema" construct in between the database and its tables has me very confused, and the PostgreSQL documentation is a little too heavy-handed (and lacking good examples) for a newbie such as myself to understand.
I'm wondering if anyone can give me a laymen's description of not only what this "schema" construct is within the realm of PostgreSQL (and how it relates databases to tables), but I'm wondering what it means to database structures in general.
Thanks in advance!
Think of schemas as namespaces. We can use them to logically group tables (such as a People schema). Additionally, we can assign security to that schema so we can allow certain folks to look at a Customer schema, but not an Employee schema. This allows us to have a granularity of control of security just above an object level but below the database level.
Security is probably the most important reason to use schemas, but I've seen them used for logical groupings as well. It just depends on what you need them for.
Late to the party, but ..
I use schemas to split tables in to groups that are used by different applications that share a few tables, for example.
users
application1
application2
Here, if we log in with app1, we see users + application1; if we log in to app2, we see users and application2. So our user data can be shared between both, without exposing app1 users to app2 data. It also means that a superuser can do queries across both sets of data.
As Mysql, sql server, postgre sql etc are basically different implementation of the same concept (rdbms), I am wondering does the same relationship exists between LDAP and MongoDB/CouchDB etc, or is there something more into LDAP?
LDAP
Hierarchical Database model (based on parent/child relationships, like in XML)
LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm
Scalable
Standard protocol
Not suited for applications that require data integrity (banking, ecommerce, accounting). Traditionally is used to store users, groups, SSL certificates, service addresses, but is a generic database and can be used for any information.
MongoDb
Document oriented Database, based on BSON (JSON-like) documents
Key value database, but values can be BSON documents
High performance in both read and write operations
Scalable (Master-Slave replication)
Custom protocol
Not suited for applications that require data integrity (banking, ecommerce, accounting)
CouchDb
Document oriented Database, based on JSON documents
Key value database, but values can be JSON documents
High performance in both read and write operations
Scalable (Master-Master replication with conflict resolutions)
REST protocol
Not suited for applications that require data integrity (banking, ecommerce, accounting)
The most important thing, which differs LDAP databases from other noSQL, like MongoDB or CouchDB, is very flexible ACL system.
For example, you can grant access to the object in the tree, using groups and users stored in the same tree. In fact, you can use objects itself to authenticate against the LDAP server.
IMHO, it is completely safe to allow clients to get access to the LDAP tree directly from the Internet without writing a string of code.
In the other hand, LDAP has a bit archaic design and uses sophisticated approaches to provide trivial operations. Mainly because of that fact, I'm slipping and dreaming, about someone implemented LDAP-like ACL in the any of modern noSQL database. Indeed, why making JSON-based database, if you cannot be authorized against it directly from the browser?
SCHEMA is one of the biggest differences.
LDAP data stores have a single system-wide extendable schema (which in real-world, is the the Achilles heel of ldap servers replication...).
NO-SQL has 'no schema' (-or- any schema per object, look at it however you want..).
Today I reviewed postgreSQL wiki and I found it is a ORDBMS (object-relational database management system), so I want to know is there any benefits for using postgreSql (RDBMS) behind the JPA (hibernate, eclipselink, ....) instead of a RDBMS (Mysql, ...) for performance issues or not?
As you know JPA use ORM and use JQL (java query language)
Regards
Object-Relational data is defined as structured data, which is user defined types in the database.
OR data types include:
Structs - structured types
Arrays - array types
These types are defined differently in each database, in Oracle they are OBJECT types, VARRAY types, and NESTED TABLE, and REF types.
JDBC standardizes access to OR data types using the Struct, Array and Ref interfaces.
With OR data-types you can have more complex database schemas, such as a TABLE of Employee_Type that has a Varray of Phone_Types and a Ref to it manager.
JPA does not have any direct support for mapping OR data-types, but some providers do.
EclipseLink has support for mapping OR data-types including, Structs, Ref, and Arrays. Custom mappings and annotations are used to map these, but the runtime JPA API is the same.
I would not normally recommend usage of OR data-types, as they are less standard than traditional relational tables, and do not give much benefit. Some database defined OR data-types, such as spatial data-types do offer advantages as they have integrated database support.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Structured_Object-Relational_Data_Types
I would say no. JPA is targeted at RDBMSs, and doesn't use the additional capabilities offered by ORDBMSs.
Now, PostgreSQL is also a very good RDBMS (you're not forced to use its object-oriented features, and my guess would be that most of its users don't), and you may use it with JPA without problem.
JPA is the translator between "thinking in objects" (Java) and "thinking in relations" (SQL). Therefore a JPA implementation will always speak to the DB in terms of relations. "Object Relational" stuff is ignored here.
Ignoring JPA and talking directly to the DB in "ORDBMS" speak won't buy you performance benefits in the most common cases, because ORDBMS are still RDBMS with some glue logic to look a little bit object-stylish. The data is stored in relations, all access paths are the same as pure relational access path.
If you really want to see performance benefits by switching not only the database product but the database technology (or philosophy) you should look at real Object Databases or even NoSQL.