This question already has answers here:
Relational database vs object-relational database
(1 answer)
The benefits of using an object relational database such as Oracle/PostrgreSQL vs a regular Relational database?
(2 answers)
Closed 8 months ago.
Relational databases store information in the form of related tables. I assume that, in turn, object-relational databases may also store information in the form of tables with an additional binary data field, that stores the entire object. Such an approach will allow both making quick selections and obtaining ready-made objects without the need to construct them.
Can someone explain how data is stored in object-relational databases?
Related
I am developing a multi-step data pipeline that should optimize the following process:
1) Extract data from a NoSQL database (MongoDB).
2) Transform and load the data into a relational (PostgreSQL) database.
3) Build a data warehouse using the Postgres database
I have manually coded a script to handle steps 1) and 2), which is an intermediate ETL pipeline. Now my goal is to build the data warehouse using the Postgres database, but I came across with a few doubts regarding the DW design. Below is the dimensional model for the relational database:
There are 2 main tables, Occurrence and Canonical, from which inherit a set of others (drawn in red and blue, respectively). Note that there are 2 child data types, ObserverNodeOccurrence and CanonicalObserverNode, that have an extra many-to-many relationship with another table.
I made some research regarding how inheritance should be implemented in a data warehouse and figured the best practice would be to merge together the family data types (super and child tables) into a single table. Doing this would imply adding extra attributes and a lot of null values. My new dimensional model would look like the following:
Question 1: Do you think this is the best approach to address this problem? If not, what would be?
Question 2: Any software recommendations for on-premise data warehouses? (on-premise is a must since it contains sensitive data)
Usually having fewer tables to join and denormalizing data will improve query performance for data warehouse queries, so they are often considered a good thing.
This would suggest your second table design. NULL values don't occupy any space in a PostgreSQL table, so you need not worry about that.
As described here there are three options to implement inheritance in a relational database.
IMO the only practicable way to be used in data warehouse is the Table-Per-Hierarchy option, which merges all entities in one table.
The reason is not only the performance gain by saving the joins. In data warehouse often the historical view of the data is important. Think, how would you model a change in a subtype in some entity?
An important thing is to define a discriminator column which uniquely defines the source entity.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am getting confused about PostgreSQL. In some places people are saying it's NoSQL, and in some places people are saying it's not NoSQL. I have seen something Postgres Plus which is actual NoSQL.
Can you tell me what is true?
You have been confused my marketing and buzzwords.
“NoSQL” is a buzzword describing a diverse collection of database systems that focus on “semi-structured” data (that do not fit well into a tabular representation), sharding and high concurrency at the expense of transactional integrity and consistency, the latter being among the basic tenets of relational database management systems (RDBMS).
Since SQL is the language normally used to interact with an RDBMS, the term “NoSQL” is used as a name for all these systems. Perhaps the name was also chosen because SQL, being verbose and often hard to understand, evokes negative reactions in many programmers.
Now PostgreSQL, like many other RDBMS, has added support for JSON data, which is the most popular format for semi-structured data commonly stored in NoSQL systems. Now you can say that PostgreSQL supports a certain feature commonly found in NoSQL databases.
Still, SQL is the only way to interact with a PostgreSQL database, so you couldn't call it a NoSQL database and keep a straight face unless you were in marketing.
Postgres Plus is a closed source fork of PostgreSQL, so the same applies to it.
PostgreSQL is not NoSQL.
PostgreSQL is a classical, relational database server (and syntax) supporting most of the SQL standards.
On a sidenote, I suggest doing some research into the differences and advantages. They both have a solid place and time.
PostgreSQL prides itself in standards compliance. Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard. It has full support for subqueries (including subselects in the FROM clause), read-committed and serializable transaction isolation levels. And while PostgreSQL has a fully relational system catalog which itself supports multiple schemas per database, its catalog is also accessible through the Information Schema as defined in the SQL standard.
Source
I'm new to data migrations, so I'm just wondering what the best way would be to go about migrating all of the data from the Big Table (NDB) over to Django Models (Postgres).
On the one hand, I have plenty of 'tables' that have plenty of relations (KeyProperties) and on the other, I must maintain those relations as well as port some over to general relations (GFK).
I'm not even sure how to go about doing this. I know how to create a Postgres Django DB, just not how to maintain things like, KeyProperties linking to image Blogs. How do I copy those images over and also maintain this 'FK' relation? I have quite a bit of data and would really like to maintain the structure of it.
Is there any good documents on database migrations and how its ideally done?
Any help would be appreciated!!!
Create a Postgres table just for the images (using BLOB or bytea types) and use FK relations to it.
The general question of doing database migrations is too broad to answer, please ask a more specific question. You are going to have to write custom code to split apart each entity's properties and convert them into Postgres data types.
Currently, all my collections are maintained in a single database.
I'm a little confused on when I should separate my collections into multiple databases, as some of the collections aren't necessarily related.
multiple databases:
can refine security permissions
separation of concerns
single database
easy
There are a set of tables I access all the time, and a set of tables I access about once a month. It makes some sense to open a persistent connection to a database containing my always-used tables, and open a connection to a database containing the sparsely-used tables when needed.
But is there any performance difference to having all my data in the same database? Is there any general rule-of-thumb to when to use multiple databases (other than production, development, etc.)
Check here for a similar question with some useful, more in-depth answers: Is it better to use multiple databases when you are managing independent sets of things in MongoDB?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have an upcoming requirement, and I'm unsure if EF is the right approach.
Essentially I have a Web Service Contract to implement, that has a handful of methods that return specific classes (DataContract classes with DataMember'd properties so they serialize correctly). The data that makes up the classes will be the result of queries against a backend database.
At the lowest level, I know I can just write some stored procs in the database that will return data rows that I can manually wire up to the custom classes, and call the stored procs from within a Data Layer class (calls stored procs, returns custom classes).
I'm wondering if I can use ADO.NET Entity Framework for this, however my understanding that this creates Entity classes from the database tables. My custom classes don't resemble any of the database tables. The stored procs perform aggregations and table joins to produce the classes.
Am I missing something here from what's possible with the EF? Or would I be better just going with stored procs / manually wiring up the custom classes in a data layer?
The Web Service will be hosted in SharePoint 2010 therefore I'm limited to ASP.NET 3.5. I think I'd be using Patterns and Practices to access the data layer, unless there are better ideas out there.
Given that you have indicated that you can only use .NET 3.5, you would be using EF 1.x which wasn't widely accepted in the ORM community.
EF 4.x is much improved, but unfortunately requires .NET 4.
DAAB is certainly an alternative, but you will still need to map out your Service entities from the data (i.e. DAAB isn't an ORM)
IMO EF comes into its own when used with LINQ, especially when used with queries - if you find that you are writing many SPROCs of the form GetXXXByYYY (or using lots of ad hoc or dynamic sp_executesql) to populate your entities, then a LINQ enabled ORM makes a lot of sense. However, if you only have a few heavy hitting PROCs which have well defined interfaces, then an ORM may be overkill.
If the object model of your application remarkably differs from the data model in your database then I'd stick to the classic ADO.Net + stored procedures for aggregations and table joins. My opinion is that any ORM brings more trouble than benefit in such case.