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

@Hedkost · Регистрация: 01.08.2012

Студворк — интернет-сервис помощи студентам

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

Я додумался только до такого варианта, но мне совсем не нравится его реализация.
Например у нас есть таблица Работники
1. id
2. name
3. adres
4. fired (уволен или нет)

Сама таблица Посещаемость
1. id
2. worker (worker = работники.id)
3. date
4. attend

Понятное дело, что в табличку Работники мы заполняем наших работников (к примеру их 30).
В таблицу посещаемость мы каждый день добавляем именно столько строчек, сколько наших работников(т.е. по 30+- работников в день, за год больше 10 тыс строк, как-то вообще не прикольно) и отмечаем был или не был в поле "attend".

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

Возможно как-то по-другому все можно сделать, как-то по проще? Заранее спасибо за помощь.

magirus · 28.02.2016, 11:27

Сообщение от Hedkost

сама страктура базы должна меняться постоянно.

никак. пока не придете к однозначной структуре.

@Hedkost · 28.02.2016, 11:33 **[ТС]**

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

@KEKCoGEN · 29.02.2016, 00:36

Сообщение от Hedkost

но 10 тыс строк за год, для такой обычной таблички

10тыс строк в день не будут очень большой нагрузкой на БД, а вы про год говорите =)

@Hedkost · 29.02.2016, 21:47 **[ТС]**

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

@aleksandy · 05.03.2016, 00:51

Сохраняй в БД только прогулы. Если для сотрудника нет записи в определённый день, значит он был на рабочем месте.

Новые блоги и статьи Все статьи Все блоги /
Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .

@Hedkost 2 / 2 / 1 Регистрация: 01.08.2012 Сообщений: 67

	Структура базы данных 28.02.2016, 10:12. Показов 1137. Ответов 5 Метки нет (Все метки) В общем проблема такова, нужно сделать примерно журнал посещаемости работников(колличество которых может меняться), посещаемость определялась как дата и был/не был. Но я немного растерялся, сама страктура базы должна меняться постоянно. Я додумался только до такого варианта, но мне совсем не нравится его реализация. Например у нас есть таблица Работники 1. id 2. name 3. adres 4. fired (уволен или нет) Сама таблица Посещаемость 1. id 2. worker (worker = работники.id) 3. date 4. attend Понятное дело, что в табличку Работники мы заполняем наших работников (к примеру их 30). В таблицу посещаемость мы каждый день добавляем именно столько строчек, сколько наших работников(т.е. по 30+- работников в день, за год больше 10 тыс строк, как-то вообще не прикольно) и отмечаем был или не был в поле "attend". Все более менее нормально, и можно реализовать потом индивидуальный вывод по каждому, и не важно сколько у нас работников уволилось или добавилось, но 10 тыс строк за год, для такой обычной таблички... оставляет желать лучшего. Возможно как-то по-другому все можно сделать, как-то по проще? Заранее спасибо за помощь. 0

@Hedkost 2 / 2 / 1 Регистрация: 01.08.2012 Сообщений: 67
	28.02.2016, 11:33 [ТС]
	Меняется только количество работников, одни увольняются, другие приходят... просто мой вариант ну как-то совсем кажется убогим, неужели нельзя сделать проще? 0

@Hedkost 2 / 2 / 1 Регистрация: 01.08.2012 Сообщений: 67
	29.02.2016, 21:47 [ТС]
	Возможно и так, дело даже не в нагрузке, просто хотелось как-то все сделать грамотней что-ли. Всем спасибо за ответы) 0

@aleksandy 636 / 528 / 165 Регистрация: 01.04.2010 Сообщений: 1,843
	05.03.2016, 00:51
	Сохраняй в БД только прогулы. Если для сотрудника нет записи в определённый день, значит он был на рабочем месте. 0