Nano Hash - криптовалюты, майнинг, программирование

PHP/MYSQL — как структурировать базу логов на 25 000 пользователей

Я имею дело примерно с 25 000 пользователей (сотрудников), распределенных по 5 подразделениям компании.

Для всех этих пользователей в настоящее время используется электронная таблица MS Excel. Электронная таблица состоит примерно из 35 столбцов, в которых регистрируется повседневная деятельность сотрудников.

Каждая строка представляет собой 1 действие, и в среднем происходит около 3 действий в день (никогда не заканчивающихся, что означает, что журнал просто растет и растет).

МОЙ ВОПРОС:

Я хотел бы создать базу данных (PHP/MYSQL), в которой хранится журнал действий для этих пользователей, а не файлы MS Excel.

  1. Должен ли я иметь таблицу для каждого пользователя с 35 столбцами... ведущую к базе данных с 25 000 таблиц?

  2. Или я должен хранить действия в массиве размером 35, преобразовывать его в двоичный файл и хранить в большом двоичном объекте и создавать такую ​​таблицу в год... что приводит к 1 таблице в год с 25 000 строк?

mysql php database-design
05.07.2011

  • Мне трудно сдержать, как я счастлив, что вы пришли сюда, чтобы задать этот вопрос, вместо того, чтобы искать решение. 06.07.2011
  • что означают 35 столбцов? 06.07.2011
  • позвольте мне быть более конкретным. Вот несколько столбцов из таблицы журнала Excel: ДАТА VEHICLE_ID VEHICLE_TYPE ROUTE_NR FROM TO TOTAL_TIME TOOL_A_TIME TOOL_B_TIME ОСТАНОВКИ MILES GAS ПРИМЕЧАНИЯ CREW_NAME... Больше всего меня беспокоит размер/скорость базы данных.... какая структура наиболее эффективна. 06.07.2011

Ответы:


1 
Employee
------------
employeeID
employee_name

Day
------------
dayID
day

Activity
-------------
activityID
activity_name
dayID
employeeID

Таким образом, вы можете просмотреть активность за день. Вы можете просмотреть активность сотрудника. Можно просмотреть активность сотрудника в определенный день.

05.07.2011
  • многогранник, спасибо за раскладку. Это означает, что Employee будет содержать 25 000 строк, а Activity будет содержать около 75 000 строк в день (исходя из 3 действий в день на пользователя). Разве Activity не вырастет до огромных размеров за очень короткий промежуток времени? 06.07.2011
  • стол на сутки? звучит безумно. thedailywtf.com/Articles/ 06.07.2011
  • +1. Flukyspore, из ваших 35 столбцов те, которые связаны с конкретным действием (например, Hours), затем переходят в таблицу действий. Вещи, которые имеют отношение к конкретному дню, попадают в таблицу Day (например, Holiday). Таким образом, когда 5000 ваших сотрудников работают 4 июля, вы можете выяснить, что они работали в выходной день, независимо от того, отметили ли они эту дату как выходной или нет. По крайней мере, одна из ваших 35 колонок, вероятно, такая. 06.07.2011
  • @yi_H: я совершенно не согласен. Наличие таблицы дней (а также таблицы времени с одной строкой на каждую секунду) имеет смысл во многих приложениях. 06.07.2011
  • +1, но вы можете сделать еще один шаг и создать таблицу категорий с: идентификатором, заголовком, описанием, а затем иметь идентификатор категории в таблице действий. Это избавит от необходимости писать имена/описания действий снова и снова, что сэкономит место. 06.07.2011
  • позвольте мне быть более конкретным. Вот несколько столбцов из таблицы журнала Excel: ДАТА VEHICLE_ID VEHICLE_TYPE ROUTE_NR FROM TO TOTAL_TIME TOOL_A_TIME TOOL_B_TIME ОСТАНОВКИ MILES GAS ПРИМЕЧАНИЯ CREW_NAME... Больше всего меня беспокоит размер/скорость базы данных.... какая структура наиболее эффективна. Спасибо еще раз! 06.07.2011
  • @flukyspor В любом случае вы все еще храните информацию в базе данных. По крайней мере, разделив по активности, вы сможете что-то сделать с информацией. Я бы предположил, что причина, по которой вы храните эту информацию, в первую очередь заключается в том, чтобы получить некоторое аналитическое представление. 06.07.2011
  • @flukyspor MySQL может работать с миллионами записей в базе данных, вот что делают базы данных. 06.07.2011
  • Я бы придерживался такой же активности, как вы показали в посте выше. Если это все аналитические данные, которые вам нужно извлечь. Конечно, я мог бы придумать тысячу вещей, которые я мог бы сделать с этими данными, и разработать для них гораздо более сложную базу данных, но вы лучше меня знаете свои потребности. 06.07.2011
  • @polyhedron, да, это для аналитических целей. Каждый день мы хотим иметь возможность подсчитывать итоги для каждого сотрудника с момента его начала. Я просто не был уверен, что лучше иметь базу данных с 25 000 таблиц или таблицу с миллионами строк. Как вы понимаете, это новый проект. Хотите структурировать его правильно с первого раза. Еще раз спасибо. 06.07.2011
  • Почти все поля можно было бы детализировать до другой таблицы, особенно транспортные средства и инструменты. Таким образом, вы сможете отслеживать активность транспортного средства и работу инструмента. 06.07.2011
  • @polyhedron Хорошо, я начинаю понимать картину, которую ты рисуешь. Я предполагаю, что пока аппаратное обеспечение на месте, размер базы данных/таблицы не является проблемой. Верен ли я в этом утверждении: хранение необработанных данных в больших двоичных объектах уменьшит количество таблиц, но может быть медленнее и усложнит работу процессора, поскольку информация должна быть декодирована из большого двоичного объекта, а итоговые значения должны рассчитываться каждый раз. из необработанных данных.... таким образом, плохая идея. 06.07.2011
  • точно, это не только усложняет обработку, но также экспоненциально усложняет и усложняет работу с ним, если вы когда-нибудь решите углубиться для получения дополнительных данных. 06.07.2011

    • 2

    Я бы использовал таблицу с 35 столбцами, если вы действительно используете многие/большинство этих полей для каждого действия.

    CREATE TABLE users (
    uid    INT,
    name   VARCHAR(255),
    ...
);

CREATE TABLE activities (
    uid    INT, // references users.uid
    type   VARCHAR(32),
    date   DATE,
    ... // The 35 activity-related columns
);

    И тогда я бы разделил на время. Возможно, за год, как вы предложили (это будет означать примерно до 27,4 миллиона строк на таблицу), или за месяц (около 2,2 миллиона строк на таблицу), если важна производительность поиска, а таблица за год слишком велика для хорошей производительности. .

    05.07.2011
  • Хорошо, спасибо, меня беспокоит размер и скорость базы данных. Я не совсем знаком с максимальной емкостью базы данных. Таблица активности в месяц... каков лимит таблиц, которые может хранить база данных? 06.07.2011
  • Максимальное количество таблиц, которые может хранить база данных, варьируется, но я думаю, можно с уверенностью сказать, что вы гораздо более вероятно столкнетесь с другими узкими местами, прежде чем это станет проблемой. В любом случае, с моделью, которую предлагает @Flimzy, данные за десятилетие приведут только к 120 таблицам, что не совсем безумно. С такой схемой, предполагая, что только самый последний интервал данных является очень релевантным, вы можете в конечном итоге отправить старые данные в архивную базу данных, скажем, с одной большой и медленной таблицей в год, в то время как ваша первичная база данных поддерживает годовой объем данных. столов в месяц. 06.07.2011
  • @djacobson, спасибо. Архивная база данных была бы жесткой, потому что мы подсчитываем итоги для сотрудника за всю его/ее карьеру в компании... каждый день. Но я начинаю иметь более четкое представление о том, как построить базу данных. Я просто немного беспокоился о том, что у меня слишком много столов. Еще раз спасибо. 06.07.2011
  • На самом деле, я ошибаюсь. Архивная таблица — отличная идея, так как я могу составить таблицу с итоговыми данными за год для использования в ежедневных расчетах. Медленное извлечение сведений за предыдущие годы из архива допустимо, так как это более редкая операция. Спасибо еще раз. 06.07.2011
  • Я бы порекомендовал прочитать одну или две книги о проектировании баз данных. Я читал, что это будет актуально: Хранилище данных Инструментарий. Возможно, есть книги получше на эту тему, но эта дала мне достаточно информации, чтобы почувствовать, что я смог придумать основной дизайн для нашего нового проекта, который нам очень хорошо послужил. 06.07.2011

    • 3

    Как правило, вы не хотите создавать таблицу для каждого пользователя. Если на то пошло, вы хотите иметь 1 таблицу, users, где вы будете хранить идентификаторы, имена и т. д., которые относятся только к пользовательской модели. Затем в отдельной таблице будут документироваться ежедневные действия пользователей со столбцом user_id в качестве ссылки на строку пользователя в таблице users.

    05.07.2011
    Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..