ti-enxame.com

Que tal armazenar registros únicos e suas categorias em uma tabela

Estou desenvolvendo meu próprio componente para o Joomla. Eu sei que em muitos componentes os registros únicos e suas categorias são armazenados em diferentes tabelas do banco de dados. Mas que tal armazená-los em UMA mesa usando os pais? Cada registro e "categoria" tem título, algum conteúdo/descrição, metadados, campo pai e outros dados em comum. Pais para registros são suas categorias e pais para categorias são suas categorias pai (se necessário). E na minha tabela há a coluna tipo (= registro ou = categoria) e posso apenas operá-los em meus pontos de vista. Dessa forma, minimiza as consultas sql e o número de modelos/visualizações. Entendo que é uma idéia nova e talvez estranha, mas é bom simplificar as coisas dessa maneira e que problemas podem surgir no futuro?

ATUALIZADO: E se o armazenamento das relações em uma tabela é uma má idéia, que tal armazenar títulos, conteúdo, metadados e outros dados em comum em uma tabela, mas apenas as relações dos pais (id, parent_id) em outra tabela ?

2
stckvrw

De acordo com a teoria SQL, um relacionamento 1: N deve ser representado por uma tabela. Nesse modelo, qualquer consulta pode navegar pelas informações de maneira consistente.

Esquecendo a teoria, você pode armazenar os valores de relacionamento em um campo, por exemplo, como uma matriz codificada em Json. No entanto, você precisará de alguma maneira analisar esse "campo de valores múltiplos" para gerenciá-lo. No LAMP, não é possível no MySQL e você teria que acessá-lo via PHP.

Para explorar maneiras alternativas de representar um Objeto: Jooctrine - Doctrine ORM no Joomla!

3
Anibal

Eu realmente não recomendaria fazer isso. O Joomla executa bancos de dados relacionais (mySQL, postgre etc), que são otimizados para lidar com tabelas relacionais. O que você está descrevendo está mais de acordo com o uso de um banco de dados noSQL (mongo, couchdb) que armazena documentos que geralmente consolidam dados hierárquicos. O Joomla não suporta nativamente esses bancos de dados e, como tal, eu não recomendaria usá-los em conjunto com um site Joomla, a menos que seja realmente necessário.

Eu iria com um design clássico de banco de dados relacional. O Joomla tem uma tabela #__categories e classes de categorias (e visualizações que eu acho) já configuradas para você (dê uma olhada em com_content ou com_weblinks para ver como eles são usados). Eles também têm a vantagem de usar conjuntos aninhados em vez de um simples relacionamento pai/filho ( http://en.wikipedia.org/wiki/Nested_set_model ).

Depois, testaria as consultas geradas - ficaria muito surpreso se elas fossem o gargalo do seu aplicativo. Primeiro, ative a opção de depuração do Joomla para que você possa ver as consultas sendo geradas e o tempo necessário para executá-las. Então, se você vir alguma consulta lenta, use EXPLAIN do mySQL para descobrir o que está acontecendo dentro do mySQL para essa consulta específica. 9 vezes em 10, se houver problemas de desempenho, é porque seu banco de dados está sem um índice. O uso de EXPLAIN deve ajudá-lo a descobrir se é esse o caso.

Se você estiver vendo muito código duplicado entre visualizações/modelos, etc., o local para lidar com isso está no próprio aplicativo, não no design do banco de dados. Assim, por exemplo, você pode escrever uma classe de visão abstrata que consolidaria seu código duplicado e da qual todas as outras classes de visão herdariam.

Para resumir, eu diria: crie um banco de dados relacional, faça seu aplicativo funcionar e teste se houver algum problema de velocidade. É sempre mais fácil consertar algo que se preocupa com a possibilidade de consertar um problema teórico

3
Rob Clayburn