I am just a beginner in No SQL, while learning I saw its schemaless. Yes, I understand if I have to insert data, the data structure is not required on No SQL (without creating tables or collection), but other than that what it differs from SQL in the case of schemaless? In SQL I can add new fields to table with queries and No SQL can also do that.
Please advise if I am miss understand the concept and help me get this answer.
Thanks in advance
I think you should go through with this question and answer on stackoverflow:
What does being schema-less mean for a NoSQL Database?
OR
The Value of Schema-Less Databases
Related
I'm working with Firebird 2.5. I have used MySQL table partitioning in the past to help optimize very large tables by creating partitions based on year. I would like to do the same thing, if possible, in Firebird but I'm having trouble finding any documentation.
Does anyone know if this is possible and if so, can you please point me toward some documentation?
Firebird does not support table partitioning, which is also why you can't find anything about it in the documentation.
Depending on the exact performance problem you're trying to solve and the queries you use, choosing your indexes well may already solve part of the problem.
I have an existing relational Postgresql database. A few of the tables contain very fat blobs, they would be much better of as NoSQL Documents. This would significantly lighten our relational database.
So, we thought of moving those blob-table out into a NoSQL solution like CosmosDB or MongoDB. However there are foreign key dependencies with purely relational tables and this complicates moving those tables out into their own database.
I have found that PSQL natively supports storing Documents and can be distributed. The solutions I looked at so far are CitusData and Postgres XL. For those who used those how do they compare?
Has anyone encountered similar situations before? Did you separate out into a NoSQL database? Or has anyone partitioned their PSQL into relational and NoSQL parts? How did that go? What would you recommend to look out for in hindsight?
(Citus Engineer Here)
Postgres has JSONB column type which is powerful and flexible. What you can do is to keep your structural table as is and put a jsonb column for the blob data. Test this with single node Postgres and if that works for you, great!
If you have a problem with the scale of your data, i.e. memory or storage or CPU of a single machine is not enough for your workload and you cannot go bigger, then you can try scaling out with Citus or Postgres-XL.
I have no experience with Postgres-XL but Citus is pretty easy to try. There are docker images that you can use or you can create an account on Citus Cloud to try a 1-week free dev plan (it would not be suitable for benchmarking purposes).
Every RDBMS->NoSQL migration would require one of the two:
1. embedding some of these dependent documents into the ones that are actually queried by the user
2. referencing dependent documents by id and inferring these relationships on read.
Very typical, everyone does it every day, don't be afraid. BTW, you don't have to make a choice between Cosmos DB and MongoDB - just use Cosmos DB with MongoDB API.
Module pg-promise provides method sequence to execute infinite sequences, suitable for massive transactions, like bulk inserts, with way over 1,000 records. And it supports query streams for high-performance, read-only queries.
Does Sequelize offer anything similar to those things?
Sorry for asking such basic things, but I am new and don't have any idea about these two.
Thanks for your response and suggestions.
This answer will probably anger some of the Sequelize fans, but in the name of truth...
What you're referring to within pg-promise is fully documented in Data Imports.
And no, Sequelize doesn't have anything like that.
And in addition, Sequelize is known to be plagued by performance issues, like this one: Transactions extremely slow when inserting 1000s of records, ones that are very bad and very old at the same time.
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.
We have Sql server database and it is designed on snow flakes (Facts and Dimensions) schema. These tables don't have PK and FK relationship. Instead we are maintaining these information in metadata tables.
Is it possible to design reports in SSRS on these tables?
I want to design reports by combining different columns from tables.
Any help would be appreciated.
Assuming that the Fact and Dimension tables are held in a conventional relational database, you can access them in SSRS using conventional SQL queries.
If the database structure is OLAP, you'll need MDX to query instead of T-SQL
yes, of courser you can!
It doesn't matter how your data is structured on your database, if you manage to build a query to display it, SSRS will be able to read it on a DataSet and use it on the report
A SELECT statement is sufficient. A view or a stored proc are preferred. It's hard to imagine a SQL database that doesn't support those options.