I have a two tables events and bookings, which are linked by event_id.
Example:
CREATE TABLE `bookings` (
`booking_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`event_id` int(10) UNSIGNED NULL DEFAULT NULL,
`fullname` varchar(80) NOT NULL,
`phone` varchar(20) NULL DEFAULT NULL,
`note` text NULL,
`date_created` datetime NOT NULL,
`date_updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`booking_id`),
FOREIGN KEY (`event_id`) REFERENCES `events` (`event_id`) ON DELETE SET NULL ON UPDATE CASCADE,
INDEX `event_id` USING BTREE (`event_id`),
INDEX `source_id` USING BTREE (`source_id`)
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci
ROW_FORMAT=COMPACT;
#events
CREATE TABLE `events` (
`event_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT ,
`date` date NOT NULL ,
`title` varchar(255) NULL DEFAULT NULL ,
`description` text NULL,
PRIMARY KEY (`event_id`, `date`),
UNIQUE INDEX `date` USING BTREE (`date`) ,
INDEX `event_id` USING BTREE (`event_id`)
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci
ROW_FORMAT=COMPACT;
I’m wondering, can I use date field as reference between tables, as it’s consume 1 byte less comparing to integer and it is easier to read and operate with single table rather than combined.
But I’m not sure how does it affect indexing and SQL query performance.
It is not a good idea to use a pure data field as a link between tables. A
datefield appears to be a general purpose field intuitively, so another engineer would eventually update the field for sensible application purposes. If it were used as a table link, updates would break the linkage.Why not create a specific field for table linkage purposes? Sure, it might cost 4 or 8 bytes per record, but have you looked at the cost of storage? It is almost free. On the other hand, a non-intuitive use of a field might cost quite a bit in future errors, misunderstandings, confusion, and downtime.