Имена файлов в базе. Какие варианты?

Имена файлов в базе. Какие варианты?

Требуется разработать систему наименования файлов в базе проектов.

  1. К базе обращается несколько (5) подразделений от менеджеров до проектировщиков, файлы с различными расширениями (около 10 различных программ), количество проектов от 30.
  2. Существуют критерии точной идентификации по имени файла: наименования проекта, даты создания или изменения, раздела проекта, стадии проекта, №договора, шифра архива и т.д. Файл по необходимости кочует с компа на комп и требуется его безусловное распознавание.

Проблема: слишком много инфы %( для одного имени файла.

Специалисты, откликнитесь. Какие существуют системы? Какая логика при наименовании? Русские или английские буквы?

251
Комментарии (11)
  • 30 марта 2009 в 03:23 • #
    Игорь Цесельский

    Арина, это откат к временам файловых серверов?
    Именем файла задача не решается - проверено, особенно отслеживание версий и изменений.
    Мы пошли по пути SharePoint Portal Server и решили проблему.

  • 30 марта 2009 в 20:54 • #
    Арина Пономаренко

    Игорь, есть множество не столь продвинутых компаний, для которых файловый сервер не откат назад, а обычная практика. Применять в нашем случае SharePoint Portal Server пока преждевременно, многие функции останутся не востребованы, а внедрение отнимет драгоценное время. Пока проблемой является только идентификация файла в базе и в архиве. Количество проектов и функции достаточно прозрачны для участников процесса и нет проблем, описанных в пресс-релизах SharePoint Portal Server. Я думаю, что почувствую, когда подойдет момент внедрять что-то более автоматизированное. Я у Вас как-то спрашивала о размере организации, для которой необходимо автоматизированное управление проектами. Вы мне ответили, что размер значения не имеет. Но как скоро отработаем мы такие инвестиции, если организация 30 человек?

  • 31 марта 2009 в 13:58 • #
    Игорь Цесельский

    Арина, уточню, что я имел в виду, когда (сейчас не вспомню, где) говорил про независимость от размера организации.
    Я не очень согласен с часто и не кместу употребляемым термином "автоматизация". Скорее, речь идет о простой механизации процесса, тк автоматизация по сути своей предполагает устранение человека из процесса, что в УП - нонсенс. На самом деле, мы управляем людьми и событиями, а не графиками и отчетами. Но это так, заметки о предмете и ИМХО.
    В связи с этим, когда речь идет о СУП, отчего-то сразу заводят речь об инструменте. А ведь главное - это сама система (а инструмент вторичен).
    В этом ключе, безусловно, размер организации никакого значения не имеет, просто надо употреблять адекватные этому размеру, и, что более важно, области, количеству, номенклатуре и масштабности проектов организации, инструменты.
    Я никогда не утверждал, что практика применения отработаннго и привычного файлового сервера - недопустима или порочна. Точно также, как и то, что SPPS - это панацея. Однако вы сами заметили своим вопросом, что файловая организация проекта служит существенным ограничением и с какого-то момента перестала вас удовлетворять. Длинные имена файлов не удобны, короткие неинформативны.
    Например, в области разработки ПО есть своя специфика, как тестирование продукта, большое количество итераций типовых процессов, отслеживание версий и массовая удаленная работа исплонителей и тп, в связи с чем многим более подходящим на сегодня представляются технологии SaaS.
    В области Вашей организации, как правило, есть необходимость работы с большим количеством организаций-контрагентов и с генподрядчиком (если вы сами не выступаете в этой роли), Это если я правильно понимаю вашу специфику. ибо занимаюсь инженерными системами в строительстве.
    В связи с этим есть потребность в консолидирующем инструменте с достаточно защищенным доступом по WWW. Безусловно, e-mail такую функцию до определенного предела выполняет. Дальше - один из выходов в портальной технологии. Неисключительно.

  • 31 марта 2009 в 20:25 • #
    Арина Пономаренко

    Все так. Просто при попытке всех загнать в определенные рамки вступают в силу и другие ограничения (кроме файловой организации, здесь обсуждаемой). Это в первую очередь, как я уже писала, размер вложений денег, сил и человеческих ресурсов по внедрению. Это и тихое нежелание менять что-то в устоявшейся практике, когда людям еще не очевидны минусы сложившейся ситуации. Они только начинают маячить передо мной, как перед руководителем, но количество должно естественным образом перерасти в качество, чтобы принять решение. Пока всё под контролем, так как количество проектов не достигает такой критической величины. Это и разные формы организации у наших субподрядчиков, которым это может быть вовсе не нужно.
    В любом случае, спасибо за возможность еще раз взвесить эти вопросы и заглянуть в перспективу.

  • 30 марта 2009 в 13:38 • #
    А Ярков

    ну если спец среды нет а просто пользуетесь общей папкой на сервере - как бывает у проектантов - то есть вариант такой
    1. делается папка с шифром объекта и названием или дата и название (09-03-30 Бизнес-центр А)
    2. внутри для каждого отдела делается папка с их названием - например АР ОВ Э (думаю понимаете что это?)
    3. Ну и каждый файл обзывается по формуле шифр объекта, шифр отдела и название или дата, название, шифр отдела и название (09-03-30 Бизнес-центр А АР Общий план)
    Здесь главное у отделов поспрашивать поймут они или нет - а то потом недопонимания будут

  • 30 марта 2009 в 20:59 • #
    Арина Пономаренко

    Получаются длинные имена. Понимают, но не очень любят это все прописывать. Что-то подобное у нас уже есть. Спрашиваю здесь на сайте, может у кого-то есть свое ноу-хау. Интересно, как выходят из положения в таких случаях или продолжать так же П_АР_ГП_.....?

  • 31 марта 2009 в 07:18 • #
    А Ярков

    Если не ставить ПО для групповой работы с файлами - то вот только так и причём прописать формулы писменно с примерами и каждому наклеить рядом с компом, иначе будет творчество сотрудников. Если сотрудников работающих вместе не более 50 - то подобной штуки хватает и всякое ПО можно забыть.

  • 31 марта 2009 в 20:15 • #
    Арина Пономаренко

    Спасибо за совет о наклейке, супер, мониторы теперь всем обклею...

  • 31 марта 2009 в 14:42 • #
    Игорь Цесельский

    Попробовал вспомнить, как было организовано файловое хранилище у нас в 2002 г. до перехода на SP. Вот что получилось (не затрагивая моменты управленческого учета, постпроектного сопровождения, исполнения проектов, складов и тп).
    1. На файловом сервере созданы папки для каждого сотрудника по его имени - они работают только в них.
    2. Созданы папки (условно) Проекты, Архив проектов, Реестр проектов.
    3. В папке Проекты по мере открытия создаются папки по каждому проекту с 3-значным цифровым индексом по учетному номеру проекта. Учтет проектов ведется в xls-файле.
    4. В каждой такой папке создаются папки и подпапки по видам систем + папки с общими данными (Исходные данные, ТЗ и тп)
    5. Имя файла - короткое и понятное без шифров и сокращений - только информация о сути содержимого.
    6. Особенность организации - доступ в эти папки для всех - на чтение, для начальников отделов , ГИПов (по их объектам) - на изменение.
    Выделен ОДИН человек (который делегирует права только на время своего отсутствия также только заместителю) из числа проектантов с технической функцией ведения реестра. ведения архива, копирования готового файла из личной папки проект-ка в указанную папку по письму-указанию ОДНОГО ответственного за проект (или его зам) - после утверждения и проверки.
    Никакого деления по отделам - только по проектам.
    7. Также создаются общие папки с материалами по проеектированию отдельных систем, НТД и тп с ответственными за каждую с полным доступом, остальные на чтение.

    Ну, есть масса ньюансов, но главное - правильно распределить систему доступа, ответственность - персональную, делегирование полномочий.

    PS В SPPS это достигается намного проще и отслеживается гораздо легче+доступ через WWW+поддержка версионности+хранение в БД (надежность) и тп.

  • 31 марта 2009 в 20:14 • #
    Арина Пономаренко

    Спасибо, Игорь, за комментарий, это очень подходит нам по сути. Конечно, все подобные мероприятия мы провели и разграничили доступ и разместили инфу по проектам, придумали шифр очень короткий для идентификации файлов. Плохо только с дисциплиной, не всегда все так как хотелось бы.. :) Работаем над ситуацией.

  • 1 апреля 2009 в 05:30 • #
    Игорь Цесельский

    В данном случае - дисциплине проще научить 1-2, чем всех, тем более, что ответственный горд доверием и блюдет).

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?