Multi-value fields stored as arrays, not comma-delimited strings
Why it matters
Comma-delimited strings cannot be indexed for faceted search, cannot be filtered in SQL without LIKE '%value%' scans, and produce false matches (Parking matches No Parking). Consumer APIs that expect arrays get strings and either crash or display literal WiFi, Parking, Outdoor Seating as a single tag. Migrating later requires a string-split backfill that is brittle when values themselves contain commas, and every downstream integration that already parsed the string must be updated simultaneously.
Severity rationale
Low because the data is recoverable and rarely user-facing in raw form, but it blocks filtering and structured data generation.
Remediation
Store multi-value fields as native arrays in Postgres (text[]) or a relational join table, never as delimited strings. Define them as array types in your Prisma schema at prisma/schema.prisma and update API serializers to emit JSON arrays. Migrate existing comma-delimited rows with a one-time SQL job that splits and trims, then drops the old column.
model Listing {
id String @id @default(cuid())
name String
categories String[]
amenities String[]
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Listing Data & Schema Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from directory-listing-schema·automated