отдельные или разделенные таблицы для хранения этой записи в базе данных? - PullRequest
0 голосов
/ 28 февраля 2012

Я боролся с проектным решением о том, как хранить эту информацию в таблицах.

У меня есть таблица с именем property, которая содержит запись для объектов недвижимости.

CREATE TABLE `property` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `addDate` datetime NOT NULL,
  `serial` varchar(30) NOT NULL,
  `title` varchar(100) NOT NULL,
  `description` text,
  `user_id` int(11) NOT NULL,
  `area_id` int(11) NOT NULL,
  `category_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE  KEY `serial` (`serial`),
  FOREIGN KEY (`user_id`) REFERENCES `user`(`id`),
  FOREIGN KEY (`area_id`) REFERENCES `area`(`id`),
  FOREIGN KEY (`category_id`) REFERENCES `category`(`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Мне нужно отобразить 5 рекомендуемых свойств и 5 свойств hotDeal, предлагаемых владельцем сайта, на странице индекса компаний. Я не могу решить, держать ли запись в одной или двух разных таблицах.

например.

CREATE TABLE `property_featured` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `addDate` datetime NOT NULL,
  `description` text DEFAULT NULL,
  `position` tinyint(1) DEFAULT '0',
  `property_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `position` (`position`,`property_id`),
  FOREIGN KEY (`property_id`) REFERENCES `property`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `property_hotdeal` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `addDate` datetime NOT NULL,
  `description` text DEFAULT NULL,
  `position` tinyint(1) DEFAULT '0',
  `property_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `position` (`position`,`property_id`),
  FOREIGN KEY (`property_id`) REFERENCES `property`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

какой подход я должен использовать, одиночный или разделенный?

1 Ответ

2 голосов
/ 28 февраля 2012

Вся информация точно такая же, поэтому вы должны использовать одну таблицу с дополнительным столбцом, называть ее как хотите и сделать ее TINYINT (0 или 1), если есть только два возможных значения, или возможно VARCHAR, если в будущем может быть больше значений.

...