Database Structure and Metadata

Multi-Schema, Single Database Approach

MemberJunction operates within a single database container, an approach that utilizes a multi-schema strategy within this container. In the context of SQL Server, this container is capable of housing numerous schemas. A schema, in this framework, acts as a sub-container within the overall database, capable of hosting a variety of different database objects. This includes not only tables but also views, stored procedures, etc.

This approach allows MemberJunction to manage and organize its data effectively.

By utilizing multiple schemas within a single database, MemberJunction can separate and categorize data logically while maintaining an integrated system.

This setup is essential for the efficient operation and scalability of the platform. MemberJunction maintains its own metadata in a schema that is logically referred to as mj_core, however in practice it defaults to being called admin inside the SQL Server database. It is possible to rename the MemberJunction core schema, however, this requires configuration of the CodeGen tool as well as the MJAPI layer to use the revised schema name.

Metadata Management and Its Advantages

Metadata in MemberJunction serves a crucial role, extending beyond the basic information stored in the database schema. It includes descriptive information such as user-friendly display names for tables, columns, and more, which are not typically stored in the underlying system catalogs of relational databases like SQL Server. This supplementary metadata provides a richer, more informative context for the data, which is essential for a comprehensive understanding and user-friendly interaction with the database.

Additionally, MemberJunction employs a separate metadata table for entity relationships, providing further descriptive information about the connections between tables. This metadata goes beyond the relational links and delves into the logical associations within the data, user-centric descriptions, and settings for generating user-interface elements as well.

Abstraction Layer for Database Structure

A key architectural decision in MemberJunction is the creation of an abstraction layer between the underlying database structure and the rest of the infrastructure.

📘

While the current release supports only Microsoft SQL Server, the intent is to enable multi-provider capability in the future.

This abstraction layer is pivotal in achieving this goal.

By maintaining a metadata structure that is separated and abstracted from the physical implementation in SQL Server, MemberJunction gains a level of flexibility and portability. It allows the system to interact seamlessly with different data providers, each potentially having different underlying structures but presenting a unified, consistent interface to the rest of the MemberJunction system.

For instance, if a NoSQL database such as MongoDB were to be used as a provider in the future, a provider would need to be created to implement that support. The future MongoDB provider would need to implement the same metadata concepts as SQL Server, albeit potentially in a format more suited to a non-relational environment (e.g. you might have a document for each entity with all aspects of the entity in a hierarchical JSON or XML structure within that document). This implementation would still need to present the data in a way that aligns with the established MemberJunction metadata and abstraction layer, ensuring consistency across different data storage solutions. The MongoDB provider would be responsible for mapping whatever its native storage method is for the various elements of metadata into the format expected of a MemberJunction Provider sub-class.