В этом ситуации я бы пошел на хранение документов, ориентированных на документ, вместо того, чтобы принуждать их к реляционной структуре данных. Данные не являются естественно реляционными, поэтому вся система будет легче писать и намного эффективнее, если вы ее разработаете таким образом.
Под документом, что я имею в виду, является то, что когда запрашивается услуга, приложение использует шаблон документа для представления формы пользователю, а затем захватывает пользователя как отдельный документ, а не несколько столбцов данных или нескольких таблиц ,
Существует много вариантов формата документа, два из наиболее популярных - JSON и XML. Если вам нужна помощь с плюсами и минусами и т. Д., Я думаю, что это должен быть отдельный вопрос.
Для хранения ваших документов вы можете просто использовать файловую систему или BigTable. Вы даже можете хранить документы в виде одного столбца в реляционной базе данных, но я бы настоятельно призывал вас отказаться от этой опции.
Ваша схема базы данных будет выглядеть примерно так:
/*!40101 SET NAMES utf8mb4 */;
CREATE DATABASE IF NOT EXISTS `services` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci */;
USE `services`;
CREATE TABLE IF NOT EXISTS `organization` (
`organization_id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`organization_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE IF NOT EXISTS `request_service` (
`request_id` int(11) NOT NULL AUTO_INCREMENT,
`organization_id` int(11) NOT NULL,
`service_id` int(11) NOT NULL,
`service_type` int(11) NOT NULL,
`document` LONGTEXT NOT NULL COLLATE 'utf8mb4_unicode_ci',
`tracking_no` int(11) DEFAULT NULL,
PRIMARY KEY (`request_id`),
KEY `FK_request_service_service` (`service_id`),
KEY `FK_request_service_organization` (`organization_id`),
CONSTRAINT `FK_request_service_organization` FOREIGN KEY (`organization_id`) REFERENCES `organization` (`organization_id`),
CONSTRAINT `FK_request_service_service` FOREIGN KEY (`service_id`) REFERENCES `service` (`service_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE IF NOT EXISTS `requirement` (
`requirement_id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,
`requirement_type` int(11) NOT NULL,
PRIMARY KEY (`requirement_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE IF NOT EXISTS `restriction` (
`restriction_id` int(11) NOT NULL AUTO_INCREMENT,
`service_id` int(11) NOT NULL,
`is_allowed` bit(1) NOT NULL,
`for_active_only` bit(1) NOT NULL,
PRIMARY KEY (`restriction_id`),
KEY `FK_service_restrictions_service` (`service_id`),
CONSTRAINT `FK_service_restrictions_service` FOREIGN KEY (`service_id`) REFERENCES `service` (`service_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE IF NOT EXISTS `service` (
`service_id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,
`requirement_id` int(11) NOT NULL,
PRIMARY KEY (`service_id`),
KEY `FK_service_list_of_requirement` (`requirement_id`),
CONSTRAINT `FK_service_list_of_requirement` FOREIGN KEY (`requirement_id`) REFERENCES `requirement` (`requirement_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
ли вы посмотреть в составные ключи? Вот ссылка http://stackoverflow.com/questions/5835978/how-to-properly-create-composite-primary-keys-mysql –