БД Учет заправки картриджей

Делаю базу данных Учет заправки картриджей. Накидал быстренько схему
Посмотрите пожалуйста подойдет такая, может чего то не хватает? Так же наверно нужно сделать за год или несколько лет? и поиск за конкретное число или по номеру картриджа.

Вложения

УчетКартриджей.rar (17.6 Кб, 316 просмотров)

0

Сообщение от Cdelphi78 Так же наверно нужно сделать за год или несколько лет?

А зачем за месяц, за год, ... ? Просто Заправка - определить по дате год, месяц и т.п. - это разве проблема?

0

ltv_1953, да точно лучше все в кучу сделать наверно, а потом делать выборку за месяц, год?

0

Угу. Если в базе больше ничего не будет (и версия не старше 2010), то делайте сводную таблицу - там и фильтры, и группировки, и итоги - встроенные. Если 2013 и старше - то придется, увы, делать сводную в Экселе (читая данные из Аксесса) .

0

Кстати наверно лучше еще цену прикрутить и вид ремонта-заправка или восстановление. Как то так в итоге примерно:

Миниатюры

 

0

Сообщение от ltv_1953 то придется, увы,

Что значит увы?
Вообще то наверно в Acsess будет прототип, а сама база на php+Mysql)

Добавлено через 1 минуту
посмотрю не знаю авторизацию долго прикручивать или нет, может авторизацию еще сделать)

Добавлено через 1 минуту
а какие итоги?) итог один-база картриджей)

Добавлено через 18 секунд
простенькая

0

Я начал дальше читать по этой теме, что то запутался и в итоге все равно не пойму как связать то эти таблички ? правильно.

Миниатюры

 

0

не вижу хозяина катриджейбдаты сдачи/возврата --только какие-то обезличенные строчки

0

shanemac51, что то я не понял, что значит нет хозяина, какого хозяина? авторизацию? Ну я собирася сделать авторизацию то есть нужная еще таблица пользователей тока. Дата есть приема и отправки.

0

кто то ведь сдает эти катриджи на зарядку/ремонт ---это и есть хозяин, владелец катриджей

0

shanemac51, хм, и куда его и зачем он?)

0

Вообщем покопался в картриджах и решил переделать схему, как то вот так,
не знаю как правильно будет никак не могу понять внешние ключи нужны вообще или нет.

Миниатюры

 

0

Что за ошибка?

Миниатюры

 

0

Сообщение от Cdelphi78 Вообщем покопался в картриджах и решил переделать схему, как то вот так, не знаю как правильно будет никак не могу понять внешние ключи нужны вообще или нет. Миниатюры

Предлагаю такой вариант:

Таблицы
0. Фирма/Клиент (Добавить: адрес, телефон, % скидки)
1. Сотрудник (ИД, ФИО и т.д.)
2. Тип картриджа (лазерный, струйный и т.д.)
3. Модель картриджа (буквенно-цифровой код)
4. Картридж (добавить: ИД Тип картриджа, ИД Модель картриджа)
5. Вид услуги (заправка, восстановление и т.д.)
6. Статус услуги
7. Прайс (ИД, ИД картриджа, ИД вид услуги, стоимость работ)
8. Заказ:
8.0. ИД
8.1. ИД Клиент
8.2. ИД Прайс
8.3. ИД Статус услуги
8.4. Дата приемки от клиента
8.5. Дата получения клиентом
8.6. Итоговая стоимость
8.7. Скидка
9. Т.к. по каждому изделию может быть оказано 1-N услуг, считаю, что следует ввести таблицу, которая будет связывать конкретный Заказ со списком услуг, оказанных по нему:
Заказ-Прайс
9.0. ИД
9.1. ИД Заказ
9.2. ИД Прайс
9.3. ИД Сотрудник
9.4. Дата начала работ
9.5. Дата окончания работ

Зачем таблица Заказ-Прайс. Например картридж можно просто заправить. А можно перепрошить и заправить. А можно просто перепрошить. А можно и перепрошить, и поменять бараран, и заправить, и пересобрать и т.д. Создавать же в Прайсе такие длинные комплексные услуги нецелесообразно.

0

chronicler, У меня сейчас уже вот так и я почти доделал БД, но я похоже сижу на каких то граблях и не пойму как с них слезть, я так понял нужны внешние ключи вместо подстановок но как и зачем их пристроить я что то не врублися вчем отличие),

0

Вот это лишнее

Сообщение от chronicler 0. Фирма/Клиент (Добавить: адрес, телефон, % скидки) 1. Сотрудник (ИД, ФИО и т.д.) 2. Тип картриджа (лазерный, струйный и т.д.)

Какая фирма? Какой сотрудник ?Зачем сотрудник?
Это тоже:

Сообщение от chronicler 8. Заказ: 8.0. ИД 8.1. ИД Клиент 8.2. ИД Прайс 8.3. ИД Статус услуги 8.4. Дата приемки от клиента 8.5. Дата получения клиентом 8.6. Итоговая стоимость 8.7. Скидка 9. Т.к. по каждому изделию может быть оказано 1-N услуг, считаю, что следует ввести таблицу, которая будет связывать конкретный Заказ со списком услуг, оказанных по нему: Заказ-Прайс 9.0. ИД 9.1. ИД Заказ 9.2. ИД Прайс 9.3. ИД Сотрудник 9.4. Дата начала работ 9.5. Дата окончания работ

список услуг отдельный конечно неплохо но времени нет просто городить большую базу) Возможно в дальнейшем я и допилю ее для себя)

0

Cdelphi78, В таблице Учет работы нужны FK на:
Фирмы
Вид работ
Статус
Картриджы

Я не совсем понял, зачем в таблице Картриджы поле Фирма.
Насчет Модель-Серия - тут я не в курсе если честно. Если под одной скажем серией могут проходить несколько разных картриджей - нужна таблица Серия. Аналогично и для модели. В противном случае просто поле в таблице.

список услуг отдельный конечно неплохо но времени нет просто городить большую базу) Возможно в дальнейшем я и допилю ее для себя)

Ну в принципе да, если времени особо нет, лучше не усложнять. Хотя с другой стороны если это все пойдет в реальную работу, то честно говоря лучше сразу базу выстроить пусть даже с кажущейся здесь и сейчас некоторой избыточностью, чем после переделывать.

0

Сообщение от chronicler Cdelphi78, В таблице Учет работы нужны FK на:

Аааа, это просто банально может добавить эти ключи в эту таблицу вместо подстановок а подстановки убрать и связь поставить один к многим? Щас перерисую.
А отдельную таблицу не надо связующюю?

Сообщение от chronicler Фирма.

Это фирма производить картриджа , не знаю показалось нужна по фирме быстренько искать кардриджи,
вообще согласен есть лишниее поля но фиг его знает нужны или не нужны и как делать, сварганить уже как нибуть курсач и отправить на проверку. авось проканает, времени нет просто разбираться.

Добавлено через 1 минуту

Сообщение от Cdelphi78 Аааа, это просто банально может добавить эти ключи в эту таблицу вместо подстановок а подстановки убрать и связь поставить один к многим?

Тока не понял в чем вся соль щас еще раз гляну лекцию.

0

Сообщение от Cdelphi78 А отдельную таблицу не надо связующюю?

Отдельная таблица для связи нужна если есть множественная связь. Например по 1 Заказу может быть N услуг. Тогда в таблице услуг создаются записи, каждая из которых хранит в том числе ИД на соответствующий заказ. А тут в таблице Учет работ на 1 клиента приходится 1 статус, 1 вид работ и т.д. Количество картриджей я бы только убрал из таблицы Учет работ, потому что клиент может принести несколько разных картриджей и стоимость работы по каждому может отличаться. Но если это просто курсач, может и не надо углубляться, действительно.

Сообщение от Cdelphi78 Это фирма производить картриджа , не знаю показалось нужна по фирме быстренько искать кардриджи

Тогда тут тоже желательно делать таблицу "Фирмы-производители картриджей" и на нее создавать FK в таблице Картриджи.

0

Сообщение от chronicler потому что клиент может принести несколько разных картриджей

Немного проясню, это база данных для организации которая отправляет картриджи на заправку другой фирме.
то есть клиентов никаких нет, сотрудников тоже просто важна например дата время и статус картриджа, чтобы админ был в курсе что у него с картриджами)

0