Tão profundamente quanto você tem tempo para. Hoje em dia, há muito desperdício em relação a ser "banco de dados agnóstico", mas, a menos que você goste da idéia de recursos de menor denominador comum que definem seus melhores esforços, você precisa saber como seu banco de dados funciona. Você obterá melhores resultados em projetos não triviais se decidir tornar seu esquema e aplicativo de banco de dados agnóstico em vez de seguir a outra direção.
A última sentença do parágrafo anterior é contra praticamente todo o conhecimento comum da Web 2.0. Vale a pena decidir onde seu projeto se encaixa no continuum "Melhor é melhor" VS "Pior é melhor".
Mas isso não significa que você deve escolher apenas um banco de dados para aprender, e o que eu realmente quero dizer é que você não deve apenas aprender um paradigma de dados. Embora os esquemas relacionais totalmente normalizados sejam sua melhor aposta para entender completamente seus dados, eles não são viáveis para muitas aplicações práticas (mas eles formam um excelente armazenamento permanente de dados, do qual você pode construir depósitos de alta velocidade personalizados para consultas específicas mais tarde, se tem os recursos). Um esquema relacional desnormalizado deliberadamente é normalmente o seu backbone, mas muitas vezes você também precisa de um banco de dados gráfico e - tão importante quanto seu esquema relacional normalizado - provavelmente precisará desenvolver um esquema de serialização as linhas de ASN.1 ou YAML, não XML, btw - data, não documentos). Se você fizer dados geográficos ou espaciais, um armazenamento de dados especializado em GIS poderá rapidamente se tornar uma necessidade também. Os bancos de dados de documentos também podem se tornar necessários se você perceber um dia que o que está fazendo (ou, mais realisticamente, algum aspecto muito carregado do que está fazendo) é, na verdade, armazenamento de documentos e não armazenamento de registros.
Tendo dito tudo isso, você precisará entender o suficiente sobre cada um para escrever uma camada de integridade intra-db (que pode ser assíncrona, portanto não entre em pânico) para que eles não se entendam. Isso requer saber como os bancos de dados funcionam.
Isso parece muito para saber, mas apenas porque é. Os dados são tão importantes. Claro, você pode ser como os caras da Web 2.0 e chutar o seu caminho ... até chegar a uma ideia realmente nova e de repente perceber que você não pode implementar praticamente a sua ideia legal. Os drives de dados usam, e não o contrário, e hoje em dia está ficando cada vez mais curto. Não seja a próxima pessoa que economizou algumas semanas fazendo um estudo genuíno da modelagem de dados (em todas as suas formas) apenas para passar a vida toda reinventando um sistema de gerenciamento de dados que vive apenas dentro do seu projeto único.
Demorei muito para chegar a essa opinião e minha evolução foi lenta. Eu não precisava de todo esse conhecimento de uma só vez; Entender os dados de uma maneira mais completa veio como um efeito colateral de interagir com aspectos mais interessantes dos problemas que emergiram ao longo do tempo enquanto eu trabalhava. (Em particular, no processo de escrever três grandes sistemas de simulação de negócios por mim mesmo.)
EDIT: Vale ressaltar que a razão pela qual eu dei uma menção especial ao modelo relacional é que é possível simular qualquer outro modelo de dados com dados relacionais, mas não necessariamente possível simular todos os outros modelos de dados de todos os outros. . O relacional normalizado é o mais geral e, portanto, o local para começar a aprender como funcionam os bancos de dados e modelos de dados (e esses são ideias relacionadas com bons bancos de dados como Postgres, DB2 e Oracle). Mas relacional puramente normalizado pode às vezes ser como tentar construir um arranha-céu com um canivete suíço se ele for religiosamente adotado. É por isso que eu digo que você deve entender seus dados de uma forma relacional totalmente normalizada, embora você não possa realmente implementá-los dessa maneira (ou mesmo em um banco de dados).
Em termos práticos, se você aprende a teoria dos dados relacionais primeiro, você vai rapidamente aumentar os pontos strongs e os comprometimentos inerentes a sistemas não relacionais (incluindo sistemas com sabor da semana) como CouchDB, AllegroGraph, ObjectDB, etc. e exatamente onde as abstrações do ORM falham (IOW, você saberá exatamente por que 1 classe! = 1 objeto table & 1! = 1 linha (nem mesmo remotamente fechada)) e aprenderá muitas coisas novas sobre programação funcional e imperativa como bem.