Kuma/prisma/migrations/20260913155733_add_discount_codes/migration.sql
2026-09-13 19:58:17 +02:00

80 lines
3.4 KiB
SQL

-- AlterTable
ALTER TABLE "CourseBooking" ADD COLUMN "discountAmount" INTEGER,
ADD COLUMN "discountCodeId" TEXT;
-- CreateTable
CREATE TABLE "DiscountCode" (
"id" TEXT NOT NULL,
"businessId" TEXT NOT NULL,
"code" TEXT NOT NULL,
"type" TEXT NOT NULL,
"value" INTEGER NOT NULL,
"scope" TEXT NOT NULL,
"courseIds" TEXT[],
"maxRedemptions" INTEGER,
"redeemedCount" INTEGER NOT NULL DEFAULT 0,
"startsAt" TIMESTAMP(3),
"expiresAt" TIMESTAMP(3),
"isActive" BOOLEAN NOT NULL DEFAULT true,
"createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updatedAt" TIMESTAMP(3) NOT NULL,
CONSTRAINT "DiscountCode_pkey" PRIMARY KEY ("id")
);
-- CreateTable
CREATE TABLE "DiscountRedemption" (
"id" TEXT NOT NULL,
"discountCodeId" TEXT NOT NULL,
"userId" TEXT NOT NULL,
"bookingId" TEXT NOT NULL,
"createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT "DiscountRedemption_pkey" PRIMARY KEY ("id")
);
-- CreateIndex
CREATE INDEX "DiscountCode_businessId_idx" ON "DiscountCode"("businessId");
-- CreateIndex
CREATE UNIQUE INDEX "DiscountCode_businessId_code_key" ON "DiscountCode"("businessId", "code");
-- CreateIndex
CREATE UNIQUE INDEX "DiscountRedemption_bookingId_key" ON "DiscountRedemption"("bookingId");
-- CreateIndex
CREATE INDEX "DiscountRedemption_discountCodeId_idx" ON "DiscountRedemption"("discountCodeId");
-- CreateIndex
CREATE INDEX "DiscountRedemption_userId_idx" ON "DiscountRedemption"("userId");
-- CreateIndex
CREATE UNIQUE INDEX "DiscountRedemption_discountCodeId_userId_key" ON "DiscountRedemption"("discountCodeId", "userId");
-- CreateIndex
CREATE INDEX "CourseBooking_discountCodeId_idx" ON "CourseBooking"("discountCodeId");
-- AddForeignKey
-- Bewusst OHNE CONCURRENTLY/NOT VALID: Postgres erlaubt CREATE INDEX
-- CONCURRENTLY nie innerhalb einer Transaktion, `prisma migrate dev` führt
-- aber jede Migration transaktional gegen eine Shadow-Database aus - dort
-- würde CONCURRENTLY hart fehlschlagen und dauerhaft JEDE künftige
-- `migrate dev`-Ausführung blockieren (nicht nur diese eine Migration), weil
-- die Shadow-DB alle Migrationen der Reihe nach durchspielt. Der Trade-off
-- ist hier vertretbar: CourseBooking existiert zu diesem Zeitpunkt zwar
-- schon, aber discountCodeId ist eine brandneue Spalte ohne bestehende
-- Nicht-NULL-Werte - Index-Build und FK-Validierung laufen daher in
-- Sekundenbruchteilen, unabhängig von der Zeilenzahl der Tabelle.
ALTER TABLE "CourseBooking" ADD CONSTRAINT "CourseBooking_discountCodeId_fkey" FOREIGN KEY ("discountCodeId") REFERENCES "DiscountCode"("id") ON DELETE SET NULL ON UPDATE CASCADE;
-- AddForeignKey
ALTER TABLE "DiscountCode" ADD CONSTRAINT "DiscountCode_businessId_fkey" FOREIGN KEY ("businessId") REFERENCES "Business"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-- AddForeignKey
ALTER TABLE "DiscountRedemption" ADD CONSTRAINT "DiscountRedemption_discountCodeId_fkey" FOREIGN KEY ("discountCodeId") REFERENCES "DiscountCode"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-- AddForeignKey
ALTER TABLE "DiscountRedemption" ADD CONSTRAINT "DiscountRedemption_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-- AddForeignKey
ALTER TABLE "DiscountRedemption" ADD CONSTRAINT "DiscountRedemption_bookingId_fkey" FOREIGN KEY ("bookingId") REFERENCES "CourseBooking"("id") ON DELETE CASCADE ON UPDATE CASCADE;