Стуктура базы данных

Собрался сделать для удобства себе лично и, возможно, остальным (посмотрим как пойдёт) небольшую систему, которая будет учитывать продажи, приход товара и т.п.
Возможно, кто-то из вас уже разрабатывал нечто подобное, ну, или просто подскажет, как спроектировать базу данных более оптимальным образом.
Картина такая:
Есть несколько министоек, на каждой такой стойке обычно по 2 продавца (продавцов могут перекидывать со стойки на стойку в случае, если нужно подменить кого-то). Каждая такая стойка ежедневно в случае необходимости получает товар. И, соответственно, каждый день что-то продает.
Нужно, чтобы учитывалось:
1. Сколько какого товара на какую стойку пришло.
2. Сколько какого товара на какой стойке продано.
3. Сколько продал конкретный продавец.
В итоге нужно будет по этим данным получать различные отчеты:
1. Сколько какого товара продано определенным продавцом.
2. Сколько какого товара продано на стойке.
3. Сравнительные данные по точкам, товару, проданному на каждой точке и т.д.
Вот какие таблицы я сделал:

1. Здесь хранится информация о количестве конкретного товара на каждой точке.
CREATE TABLE `balance` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`item_id` INT(10) NOT NULL DEFAULT '0',
	`place_id` INT(10) NOT NULL DEFAULT '0',
	`count` INT(10) UNSIGNED NOT NULL DEFAULT '0',
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM;

2. Здесь хранится информация о категориях товара:
CREATE TABLE `category` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`parent_id` INT(10) NOT NULL DEFAULT '0',
	`title` VARCHAR(50) NOT NULL DEFAULT '',
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM

3. Здесь хранится описание товара:
CREATE TABLE `item` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`category_id` INT(10) NOT NULL DEFAULT '0',
	`title` VARCHAR(50) NOT NULL DEFAULT '',
	`price` SMALLINT(6) NOT NULL,
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM;

4. Здесь — учетные записи продавцов:
CREATE TABLE `person` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`login` VARCHAR(50) NOT NULL,
	`password` VARCHAR(64) NOT NULL,
	`fullname` VARCHAR(50) NOT NULL DEFAULT '',
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM;

5. Информация о торговых точка:
CREATE TABLE `place` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`title` VARCHAR(50) NOT NULL DEFAULT '',
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
AUTO_INCREMENT=4;

6. Здесь как раз учитывается получение товара продавцом для конкретной точки и продажи товара:
CREATE TABLE `variation` (
	`id` INT(10) NOT NULL AUTO_INCREMENT,
	`person_id` INT(11) NOT NULL DEFAULT '0',
	`place_id` INT(11) NOT NULL DEFAULT '0',
	`item_id` INT(10) NOT NULL,
	`date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
	`count` INT(11) NOT NULL,
	`summ` INT(10) UNSIGNED NULL DEFAULT NULL,
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM;

Мне важна на данный момент сама структура базы данных. Тип и количество полей изменится, я думаю.
В таблице `variation` поле `place_id` для учета того, на какой точке сколько товара продано продавцом. Т.к. один день продавец может быть тут, другой — там.
Приветствуется любая критика и пожелания (какие книги мне нужно почитать?:) )
  • Вопрос задан
  • 3164 просмотра
Пригласить эксперта
Ответы на вопрос 4
@YourChief
я почитывал книгу в.м.илюшечкина, который мой преподаватель по дисциплинам проектирование субд и субд оракл. если коротко, то можно выделить два подхода к проектированию.
либо вы выделяете несколько сущностей и их атрибуты и для каждого делаете таблицу. например таблица продавцов с их фамилиями, номером смены продавца и т.п., таблица товаров с их штрихкодом, ценой и т.п. а затем устанавливаете между ними связи. можно всё нарисовать в ERWin'е и он сам инфологическую модель реализует для любой конкретной СУБД в виде запросов создания и условий целостности.
второй подход более универсальный, назывется метод декомпозиции. состоит в том, что вы при проектировании строите отношение (таблицу), содержащее все возможные атрибуты. она называется универсальным отношением или первой нормальной формой. затем выявляете между атрибутами все функциональные зависимости и декомпозируете (разделяете на связанные таблицы) отношение до тех пор, пока оно не разобьётся на несколько отношений, удовлетворяющих нормальной форме бойса-кодда. плюс метода заключается в том, что он не зацикливается на реальный смысл строк и таблиц и всегда даёт лучший результат. если не найдёте в интернете, могу попробовать найти свою литературу, где расписано всё
Ответ написан
AlexeyK
@AlexeyK
CREATE TABLE `variation` (
`id` INT(10) NOT NULL AUTO_INCREMENT,
`person_id` INT(11) unsigned NOT NULL DEFAULT '0',
`place_id` INT(11) unsigned NOT NULL DEFAULT '0',
`item_id` INT(10) unsigned NOT NULL default 0,
`date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`count` INT(11) unsigned NOT NULL default 0,
`summ` decimal(10, 2) UNSIGNED default 0.00,
PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM;


первое что в глаза бросается, я тут добавил default/unsigned и поменял тип summ, все-таки рубли и копейки, к тому же посоветовал бы использовать InnoDB, вы как-никак с деньгами работаете и думаю, что сохранность данных важна
Ответ написан
slang
@slang
Нормальная классическая структура, конечно, не хватает индексов на полях, по которым будут джойны, но, насколько я понял Вы это и сами прекрасно понимаете…
Ответ написан
steff
@steff Автор вопроса
Т.е. по структуре базы данных всё нормально, так?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы