Добрый день.
В проект входит 2 базы Access. Обе базы реализованы с помощью Microsoft Office 2003. Обе базы по своей специфики не взаимосвязаны между собой.
Это - простые учетные базы, без разных излишеств. Созданы таблицы и организованы связи между ними. Существует небольшое количество запросов (по одной базе не больше 15, по другой около 5), так же присутствует минимальное количество вычислений. На основании запросов сделано несколько сводных таблицы и отчетов.
Вся работа в базах ведется через созданные формы. Для одной из баз организован общий доступ. Файл базы помещена в сетевую папку и для нее открыт общий доступ. В ней могут работать лишь два человека параллельно. Программист очень не опытен и не смог это правильно и качественно сделать (т.е сделано самым простым способом).
Задачи состоят в следующем:
Первая база. Нужно организовать защиту. В чем она заключается:
1. База Access должна работать только на 2 компьютерах. При переносе файла с базой на любой другой компьютер она не должна абсолютно запускаться. Своего рода доступ с помощью привязки по так называемому IP компьютера (но только к двум компьютерам, без параллельно общего доступа), как это делается в программах. Почему 2 компьютера: я как администратор базы, могу перенести к примеру ее на свой домашний компьютер (второй компьютер) добавить: запрос, таблицу, форму (т.е. внести изменения ит.д.) и после чего скопировать на компьютер (основной, рабочий) где она будет работать.
2. Все существующие и при попытки добавления новых таблиц, форм, запросов база должна быть защищена. Если простым языком в существующие таблицы через формы обычный пользователь может только вносить данные, пользоваться запросами через сводные таблицы и отчеты. Другие действия, такие как: добавить новую таблицу, организовать/сменить связь через схему данных, добавить запрос, добавить новый отчет любой другой человек кроме меня не сможет это сделать. Даже чтобы окно где находится перечень таблиц, форм и т.д. не должно отображать, т.е. полностью не доступно пользователю. Это можно сделать стандартными способами в Access, но нужно что-то понадежнее.
Вторая база:
1. Задача в ней состоит в том, что она размещена в сетевой папке. Следует убрать из нее общий доступ, как это было сказано выше. Чтобы один человек мог с ней работать.
2. База будет иметь своего рода ознакомительный характер. Что имеется ввиду: в существующие таблицы через формы обычный пользователь может вносить данные, пользоваться запросами через сводные таблицы и отчеты но после тестового периода она должна быть заблокирована (или не запускаться. Это на усмотрение аффективной реализации). Либо можно чтобы она запустилась и была выведена основная форма, но данные в ней чтобы не были доступны (не удалены но чтобы в полям данные отсутствовали). Переходы с помощью кнопок управления к: запросам, отчетам были заблокированы.
3. При организации пункта 2 соответственно кроме меня как админа эту базу не сможет разблокировать и предоставить доступ работе базы данных к таблицах формам, запросам, отчетам и т.д.
Жду Ваших откликов для более детально обсуждения по возможности реализации выше описанного, сроков и стоимости
Бюджет: 500 UAH Срок: 2 дня
Здравствуйте Любовь. Есть пример защиты бд по id диска и пошаговая инструкция на создание файла рабочих групп, в котором определяются имена пользователей, их пароли и права на работу с различными объектами БД.
Есть действующая production-платформа с каталогом и автоматическим обновлением внешних предложений и цен. Стек: — Node.js / TypeScript; — PostgreSQL; — существующий price refresh service и cron; — отдельный готовый Python-модуль валидации и выбора предложений; — staging и production. Необходимо точечно доработать существующий price refresh pipeline без полного переписывания backend. ОБЯЗАТЕЛЬНЫЙ SCOPE 1. Интеграция Python-модуля — Python-модуль остаётся отдельным компонентом; — возвращает структурированный результат: offers, selected offer, statuses и risk flags; — Node.js валидирует результат и выполняет запись в БД; — предусмотреть обработку ошибок и partial/failed runs; — legacy pipeline не отключается до завершения QA. 2. Запуск refresh по списку Добавить запуск: — по одному slug/id; — по переданному списку slug/id. Допустим CLI или существующий служебный API. Новый пользовательский интерфейс не требуется. 3. Shadow Mode Новые результаты должны записываться отдельно и не влиять на production до QA. Требуются shadow-поля: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Расширение существующей таблицы offers Добавить: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags либо хранение в существующем JSON; — unique constraint для защиты от дублей. Новую параллельную offer-систему создавать не требуется, если существующую таблицу можно безопасно расширить. 5. UPSERT, STALE и DB transaction Заменить текущую схему DELETE → CREATE: — UPSERT существующих и новых offers; — отсутствующие в полном успешном snapshot offers переводятся в STALE; — при API error, partial result или незавершённом snapshot активные offers не должны становиться STALE; — обновление offers, selected offer metadata и shadow fields по одной модели выполняется внутри одной DB transaction; — при ошибке выполняется полный rollback. 6. Canonical-safe refresh Price refresh не должен изменять: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Обновляются только offer, price и shadow data. 7. Сохранение текущей cron-логики Сохранить: — existing cron; — rolling batches; — cooldown; — проверку PRICE_REFRESH_MIN_DAYS до вызова внешнего API; — legacy production pipeline до завершения Shadow QA. 8. Audit output Достаточно одного варианта: — shadow-колонки в существующей admin table; или — CSV export. Минимальные данные: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. Новый сложный dashboard не требуется. 9. Staging и QA — DB migrations; — staging deployment; — smoke test на 5 переданных моделях; — затем Shadow Mode приблизительно на 50 моделях; — исправление технических ошибок, выявленных во время этих прогонов; — краткая документация контракта Python → Node.js и rollback procedure. ОПЦИОНАЛЬНО ОЦЕНИТЬ ОТДЕЛЬНО Простой технический promotion без нового UI: — promotion одной модели по slug; — promotion списка slug; — перенос подтверждённых shadow values в production; — техническая проверка после rollout. РЕЗУЛЬТАТ — Pull Request; — DB migrations; — рабочая интеграция Python → Node.js; — Shadow Mode; — UPSERT, STALE и транзакционное обновление; — запуск по slug/id; — staging deployment; — smoke-test results; — краткая документация; — не менее 7 дней исправления багов по реализованному scope после приёмки. В ОТКЛИКЕ УКАЗАТЬ 1. Fixed price за обязательный scope. 2. Отдельную стоимость promotion-механизма. 3. Срок. 4. Оценку часов. 5. Когда готовы начать. 6. Опыт с PostgreSQL transactions, migrations и ingestion pipelines. 7. Какие вопросы нужно уточнить до начала. 8. Включены ли staging, QA, migrations и bug-fix period. Шаблонные ответы без конкретной оценки рассматриваться не будут. Доступ к production на первом этапе не предоставляется. Работа начинается с ограниченного code review и staging.
Необходимо разработать централизованную серверную систему сбора и хранения данных из Planfix, 1С, Meta Ads и Google Ads, а также веб-дашборд для их отображения и анализа. Все данные, история изменений, расчеты и агрегированные показатели должны храниться исключительно в серверной базе данных. Дашборд не должен хранить или дублировать бизнес-данные. Он должен получать необходимую информацию из серверной базы через API в соответствии с запросами пользователя и отображать ее в виде KPI, графиков, таблиц и детализированных отчетов.
Ищем для поддержки проекта на базе Yii , нужно вносить правки и доработки базы, частично есть связь с предыдущим исполнителем .....................
Необходимо сделать миграцию базы из CRM G-PLUS на MyChatBot Объем базы - 26 тыс. лидов 2 воронки - Кол центр и Отдел продаж со своими воронками Карточки лидов (кроме имени и номера) имеют много различных полей Лиды также имеют голосовые записи звонков. Их также нужно перенести От кандидата ожидаю ориентировочную сумму и сроки реализации
Создать дашборд для мониторинга и анализа эффективности сети локаций (филиалов) компании в Google Business Profile (GBP) через официальный Google Business Profile API. Обработка через Скрипт на базе Google Apps Script (привязать к Google Таблице). Запись данных в Google Таблицу (которая выступает как база данных для Looker Studio). Обновление: Ежедневно (с индикацией даты последнего обновления). Создать сервисный аккаунт Google Cloud Скрипт раз в сутки (триггер в 03:00 ночи) отправляет запрос к GBP API. Получает метрики за вчерашний день по каждой локации (locationId). Записывает данные в таблицу в плоском формате (строка = уникальное сочетание Дата + ID Филиала + Метрики). Карточки ключевых показателейНазвание карточкиМетрика GBPФормат динамикиПросмотры профиляImpressions (Search + Maps)Процент %, Sparkline (синий)ЗвонкиLocal Services Phone CallsПроцент %, Sparkline (зеленый)Переходы на сайтWebsite ClicksПроцент %, Sparkline (фиолетовый)Построение маршрутовDirection RequestsПроцент %, Sparkline (оранжевый)Средний рейтингAverage Review RatingАбсолютное изменение (например, +0.1), Sparkline (желтый)Новые отзывыNew Reviews CountПроцент %, Sparkline (бирюзовый)