Database Schema
Overview
This document describes the database schema and data persistence layer for the Business Profile Management module. The system uses MongoDB as the primary database with Mongoose as the ODM layer. The schema supports comprehensive business information, settings, media assets, and operational configurations.
Database Schema
Business Profile Collection
Collection Name: businessProfile
The business profile collection stores complete business information with the following schema structure:
{
_id: ObjectId, // Primary key (tenant ID)
published: Number, // Publication status (ActiveEnum)
name: String, // Business name
username: String, // Unique business username
description: String, // Business description
feature: String, // Featured information
facilities: [String], // Available facilities (FacilityEnum)
socialNetworkLinks: [SocialNetworkLinkSchema], // Social media links
bookingSettings: BookingSettingsSchema, // Booking configuration
businessSettings: BusinessSettingsSchema, // Business configuration
notificationSettings: NotificationSettingsSchema, // Notification preferences
paymentSettings: PaymentSettingsSchema, // Payment configuration
panelSettings: PanelSettingsSchema, // Panel UI settings
publicPageSettings: PublicPageSettingsSchema, // Public page settings
addresses: [AddressSchema], // Business addresses
schedules: [ScheduleSchema], // Operating schedules
specialSchedules: [SpecialScheduleSchema], // Special schedules
contacts: [ContactSchema], // Contact information
gallery: [ObjectId], // Gallery image references
logo: ObjectId, // Logo image reference
banners: [ObjectId], // Banner image references
stateHistory: [StateHistorySchema], // State tracking
createdAt: Date, // Auto-generated creation timestamp
updatedAt: Date // Auto-generated update timestamp
}Schema Definition
Field Specifications
Required Fields
published
Number
Publication status
Must be ActiveEnum value (0 or 1)
bookingSettings
Object
Booking configuration
Must pass BookingSettings validation
businessSettings
Object
Business configuration
Must pass BusinessSettings validation
Optional Fields
name
String
Business name
null
username
String
Unique business username
null
description
String
Business description
null
feature
String
Featured information
null
facilities
String[]
Available facilities
[]
addresses
Object[]
Business addresses
[]
contacts
Object[]
Contact information
[]
schedules
Object[]
Operating schedules
[]
specialSchedules
Object[]
Special schedules
[]
socialNetworkLinks
Object[]
Social media links
[]
System Fields
_id
ObjectId
Primary key (tenant ID)
No (set to tenant ID)
stateHistory
Object[]
State change tracking
Yes
createdAt
Date
Creation timestamp
Yes
updatedAt
Date
Last modification timestamp
Yes
Embedded Schemas
AddressSchema
ContactSchema
ScheduleSchema
SocialNetworkLinkSchema
BookingSettingsSchema
BusinessSettingsSchema
PaymentSettingsSchema
Relationships
Media Relationships
Type: One-to-One (Logo), One-to-Many (Banners, Gallery)
Implementation: ObjectId references to Media collection
Collection:
mediaLookup: Populated during queries when media details needed
Reference Integrity
Media references are managed by the application layer
Orphaned media cleanup handled by background jobs
Cascade deletion policies for media references
Indexing Strategy
Primary Indexes
Composite Indexes
Sparse Indexes
Query Patterns
Common Queries
Find Business Profile by Tenant ID
Find Published Profiles
Username Availability Check
Location-Based Search
Facility-Based Filtering
Text Search
Complex Aggregation Queries
Profile with Media Population
Business Directory Query
Repository Implementation
BusinessProfileRepository
The repository class extends BaseRepository and implements IBusinessProfileRepository:
Key Repository Methods
Standard CRUD Operations
createItemWithId(profile: IBusinessProfile): Promise<IBusinessProfile>updateItem(id: string, profile: IBusinessProfile): Promise<IBusinessProfile>findById(id: string): Promise<IBusinessProfile | null>deleteItem(id: string): Promise<void>(soft delete)
Specialized Queries
findByUsername(username: string): Promise<IBusinessProfile | null>findByIdentifier(identifier: string): Promise<IBusinessProfile | null>findPublishedProfiles(): Promise<IBusinessProfile[]>findByLocation(coordinates: number[], radius: number): Promise<IBusinessProfile[]>searchByText(query: string): Promise<IBusinessProfile[]>
Settings Management
updateBookingSettings(tenantId: string, settings: IBookingSettings): Promise<void>updateBusinessSettings(tenantId: string, settings: IBusinessSettings): Promise<void>updatePaymentSettings(tenantId: string, settings: IPaymentSettings): Promise<void>
Data Consistency
State History Tracking
Business profiles use state history for audit trails:
Media Reference Integrity
Application layer manages media references
Orphaned media cleanup via background jobs
Reference validation during updates
Settings Validation
All embedded settings objects are validated:
Multi-Tenancy
Tenant Isolation
Data isolation is achieved through:
Document-level isolation (one profile per tenant)
Tenant ID as primary key
Application-level tenant context enforcement
Tenant-Aware Operations
Performance Considerations
Query Optimization
Index Usage: Ensure queries use appropriate indexes
Projection: Select only needed fields in queries
Population: Use selective population for media references
Aggregation: Use aggregation pipelines for complex queries
Media Performance
Lazy Loading: Load media references on demand
CDN Integration: Serve media files via CDN
Thumbnail Generation: Multiple sizes for optimal loading
Compression: Automatic image optimization
Caching Strategy
Profile Caching: Cache complete profiles
Settings Caching: Cache individual settings objects
Media Caching: Cache media URLs and metadata
Query Result Caching: Cache common query results
Data Migration
Schema Evolution
When schema changes are needed:
Backward Compatibility: Add optional fields
Migration Scripts: Transform existing data
Versioning: Track schema versions
Rollback Procedures: Maintain rollback capabilities
Example Migration Scripts
Backup and Recovery
Backup Strategy
Regular Snapshots: Daily MongoDB snapshots
Point-in-Time Recovery: Enable oplog for PITR
Media Backup: Separate media file backup
Cross-Region Replication: For disaster recovery
Data Retention
Active Profiles: Keep in primary collection
Inactive Profiles: Move to archive after inactivity period
Media Files: Retain based on business requirements
Audit Logs: Retain state history for compliance
Monitoring and Alerts
Database Metrics
Query performance and execution times
Index usage statistics and efficiency
Document growth rate and collection size
Memory usage and cache hit ratios
Connection pool utilization
Alert Conditions
Slow queries (>100ms for simple operations)
Index misses or inefficient queries
High memory usage or cache pressure
Media storage growth rate
Failed operations or validation errors
Security Considerations
Data Protection
Encryption at Rest: Enable MongoDB encryption
Encryption in Transit: Use TLS for all connections
Field-Level Encryption: For sensitive payment data
Access Control: Role-based database access
Audit Logging: Track all data access and modifications
Media Security
Secure URLs: Time-limited signed URLs for media access
Content Validation: Validate uploaded file types and content
Storage Encryption: Encrypt media files at rest
Access Logs: Track media file access patterns
Privacy Compliance
Data Minimization: Store only necessary information
Right to Deletion: Support for profile deletion
Data Portability: Export capabilities for profile data
Audit Trails: Complete change history for compliance
Last updated
Was this helpful?