Db Role Laravel Package

Product Decisions This Supports

• Entity modeling: single type vs. multi-role. The core decision this package informs is whether one business entity (a "User," "Account," "Partner") can simultaneously occupy several subtypes — e.g. a person who is both a Customer and a Supplier, each with its own attributes. db-role implements class-table inheritance, so this becomes a first-class schema choice rather than a JSON blob or an EAV table.
• Schema strategy for sparse subtype data. Where role-specific columns are few and rarely queried, this pushes the conversation toward JSON columns or nullable fields; where they are numerous, query-heavy, and need constraints, it supports a "base table + role tables sharing the primary key" design.
• Build vs. buy for inheritance support. Do we hand-roll hasOne relations plus save orchestration, adopt a package, or model roles as separate aggregates joined by policy logic? This package is a concrete reference implementation of option two.
• Roadmap sequencing for multi-sided features. Relevant when the roadmap includes marketplaces, HR/employee-type hierarchies, insurance products, or CRM contacts with divergent contact types — features where retrofitting inheritance later is expensive.
• Data integrity and reporting decisions. Role tables keep foreign keys and NOT NULL constraints that polymorphic or JSON approaches forfeit, which matters for analytics, BI extracts, and audit requirements.

When to Consider This Package

Consider it only when all of the following hold:

• You have a genuine multi-role domain, not a simple single-level subtype hierarchy (for the latter, single-table inheritance is simpler).
• Role-specific attributes are substantial and need real column types, indexes, and constraints.
• Your team is small enough to read and own the package internals, and willing to fork or vendor it.
• You have run a license review — the repository reports NOASSERTION, which means the license is unstated or unrecognized. This is a hard blocker for most legal/procurement processes until clarified with the maintainer.
• You have completed due diligence on maintenance: last release date, open issues, Laravel/PHP version support, and test coverage. At 15 stars and a composite score of ~0.08, treat this as an unmaintained-risk dependency.
• You can pin the version, add integration tests around persistence behavior, and accept that security patches will be yours.

Look elsewhere when: role differences are a handful of fields (use JSON or nullable columns), you need polymorphic behavior across unrelated tables (native morphTo), you rely on a reporting layer that expects one wide table, you operate under compliance/audit regimes that require a clear license and vendor support, or you have no capacity to maintain a fork. In those cases, implement the pattern in-house or use a single-table inheritance package.

How to Pitch It (Stakeholders)

For executives: This is not a procurement recommendation. illuminatech/db-role is a small, low-adoption open-source library that demonstrates a proven database pattern — class-table inheritance — for entities that play multiple roles. Its value to us is as a design reference that de-risks the architecture decision for our upcoming multi-role domain work, not as a production dependency. Adopting it directly carries unacceptable licensing ambiguity (NOASSERTION) and single-maintainer risk.

For engineering: The package shows a clean way to give an Eloquent model multiple role relations that share a primary key, with persistence handled through the role model. It is worth a short time-boxed spike against our real schema to validate the pattern — measure query complexity, eager-loading behavior, and migration ergonomics. If the pattern proves out, our recommendation is to implement a thin internal equivalent (~a trait and a relation class) that we own outright, carrying our license and tests. Budget: one engineer, one to two weeks, including a fork-or-reimplement decision. Decision needed: approve the spike, and rule the package out as a direct dependency.