На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

Модераторы: Chow, Bas, MIF
  
> Выбор модели данных БД учета личного состава , Выбор модели данных БД учета личного состава
    Доброго времени суток, уважаемые форумчане!
    Я работаю Вооруженных Сил РФ. Учет личного состава ведётся на бумажных носителях. Для автоматизации учета хочу создать базу данных, удовлетворяющую следующим требованиям:
    1. У военнослужащего имеется около 90 параметров (учетных данных).
    2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д.
    3. Хранение записей по нарастающей хронологии, т.е. хранить сведения обо всех детях, датах и номерах приказов о присвоении званий, назначении должностей, периодах службы и т.д.
    4. Возможность вывода любых форм (отчетов) в различных комбинациях параметров (учетных данных) и подсчёт всевозможной статистики.
    5. Вывод форм (отчетов) в документы MS Word и Excel.
    6. БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью.

    Вопросы:
    1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?
    2. Возможно ли реализовать требуемую БД в MS Access или 1С?
    3. Какую литературу посоветуете по реализации моей БД?

    Заранее спасибо. Прошу прощения, если ошибся в терминах. БД изучал в университете 5 лет назад.
      Цитата flintpit @
      Реляционную, объектно-ориентированную или что-то иное?

      Реляционную + объектно-ориентированную.

      Цитата flintpit @
      2. Возможно ли реализовать требуемую БД в MS Access или 1С?

      Можно, но как быть с
      Цитата flintpit @
      но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры

      Одно из требований это установленный офис и 1С.


      Цитата flintpit @
      2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д.

      Дети это такие-же физ лица что и родители только у них должен стоять признак что они дети (отдельная таблица). Точно также и родственники военнослужащего, тети ,дяди и остальные кузины и .....
      Если отец и мать тоже военнослужащие и у них общие дети, вы же не будете вводить одного и то же ребенка дважды. Достаточно дать ссылку на физ.лицо и установить признак ребенка.

      Добавлено
      Так и с остальными структурами, типа место жительства, образования и тд и тп
      Сообщение отредактировано: Bas -
        Поставленная задача на самом деле требует не столько внимания к организации хранения данных (все озвученные данные можно хранить хоть в plain text или там XML, это несильно скажется на производительности с учётом прогнозируемых объёмов данных), сколько к интерфейсной части (создание необходимых обработок и генерации выходных форм, в т.ч. экспортируемых).

        С учётом этого настоятельно рекомендую забыть про одноэску. MS Access в принципе неплох - но возникнут озвученные выше проблемы с необходимостью наличия установленного офиса, причём именно в Проф версии, ибо в стандарте Акса тупо нет, плюс определённые сложности в связи с отсутствием штатных средств резервирования и наличием ограничений на размер БД (с учётом того, что файл БД одновременно используется и как файл-кэш для материализации промежуточных данных).

        Однако я бы предложил посмотреть в сторону альтернативных инструментов, которые специально затачиваются именно под создание связки БД+интерфейс, но при этом сами портабельны (только интерфейсный обработчик либо комплекс с БД) и содержат более вменяемый встроенный сервер БД. Например, типа MyVisualDatabase (она бесплатна для некоммерческого использования).
        Сообщение отредактировано: Akina -
          Сперва небольшое отступление. Последние 2 с половиной года разрабатывал АРМ центра социального обслуживания населения. Как оказалось впоследствии, именно грамотное построение структур учета - основной головняк разработки. Не последующие регистрации работ/консультаций/обслуживаний, а именно регистрация и учет граждан... И мне есть чего сказать :lol:

          Цитата flintpit @
          Вопросы:
          1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?

          Строго реляционную. Потому, как с помощью этого решаемо на 100%, потому как более широко используемо, потому как больше кому будет помочь советом.

          Цитата flintpit @

          2. Возможно ли реализовать требуемую БД в MS Access или 1С?

          Возможно. Но с этими двумя на практике не знаком, без комментариев.
          Цитата flintpit @
          3. Какую литературу посоветуете по реализации моей БД?

          Сперва искать ликбез по проектированию реляционных БД.

          Ну а теперь "вкусненькое" ...

          Типа броне-костюм для строевой подготовки на минном поле :lol:

          1) "Реляцоинность" данных! Без этого в будущем будут невзгоды и лишения, которые, согласно присяге, вам нужно будет преодолевать. А оно надо вам?

          Простой пример. Общеупотребимая практика. Для учета граждан создается основная таблица, состоящая из множества полей типа VARCHAR - ФИО, Адрес проживания, иногда и телефон ... Но, и фамилии меняются, и адреса, и телефоны. Со временем. А вам нужно что?

          Вместо этого собираем наши информационные сущности как из "конструктора".

          а) Создаем каталог "Описателей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Name - название (используемое в UI), например ФАМИЛИЯ
            Prompt - короткая подсказка
            Help - длинный хелп по назначению и способу заполнения
            Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия

          б) Создаем каталог "Информационных сущностей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО"

          c) Создаем каталог "Конструкторов Информационных сущностей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Target - ссылка на б)
            Info - ссылка на a)
            Cost - желаемый порядок размещения в UI


          Что в результате? В результате вместо статической структуры, известной на момент сборки - получаем возможность строить нужные нам динамические структуры на момент ввода в эксплуатацию, равно как и во время самой эксплуатации. Нужно нам 90 полей - пожалуйста, нужно 91-е поле, нет проблем - решается администрированием путем создания (при необходимости поля) и "привязки" его к нужной информационной сущности.

          2) "Версионность" данных! Вот оно самое:

          Цитата flintpit @
          Хранение записей по нарастающей хронологии

          Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа:
          ExpandedWrap disabled
            Id - уникальный идентификатор
            Date - дата изменения
            Type - тип изменения
            Rel - ссылка на новое значение
            Cause - ссылка на рубрикатор причин
            Note - коментарии

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

          3) "Журналирование" данных!

          Каждую операцию нужно журналировать. "Кто-что-когда". Это позволит в будущем делать и анализ работы учетных подразделений, и позволит, при необходимости делать откаты изменений.

          Ну естественно, не нужно путать принцип "Бритвы Оккама" с неоправданным упрощением информационных моделей.

          По поводу "движка БД" - посоветую глянуть в сторону SQLite. Сам с ней не работал, но в планах - намереваюсь.

          Удачи!

          Добавлено
          Вдогоночку. Забыл упомянуть про "Отчетность". Давно надумалось неплохое решение - если хранить отчеты, их UI-входные формы и выходные формы, в самой БД. Нет проблем не только для M$ Access! Простой пример. Сам интерфейс пишется на Qt/C++ , а отчеты хранятся в БД в виде VARCHAR, содержащие скриптовые подпрограммы на QtScript. Переработка отчетности совсем не потребует переработки программы. Более того, идеально решается вопрос дистрибуции изменений в отчетности.
            Цитата JoeUser @
            Забыл упомянуть про "Отчетность".

            "Отчетность"- выделить в отдельную тему, так как она многогранна и многолика (по способам хранения, сборки , визуализации)? Если будет обсуждение развиваться.

            Добавлено
            Цитата JoeUser @
            Сперва искать ликбез по проектированию реляционных БД.

            поиск по форуму
              Как удалить неправильно написанное сообщение?

              Добавлено
              Как удалить неправильное написанное сообщение?

              Добавлено
              Цитата JoeUser @
              Вместо этого собираем наши информационные сущности как из "конструктора".

              а) Создаем каталог "Описателей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Name - название (используемое в UI), например ФАМИЛИЯ
                Prompt - короткая подсказка
                Help - длинный хелп по назначению и способу заполнения
                Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия

              б) Создаем каталог "Информационных сущностей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО"

              c) Создаем каталог "Конструкторов Информационных сущностей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Target - ссылка на б)
                Info - ссылка на a)
                Cost - желаемый порядок размещения в UI


              2) "Версионность" данных! Вот оно самое:

              Цитата flintpit @
              Хранение записей по нарастающей хронологии

              Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа:
              ExpandedWrap disabled
                Id - уникальный идентификатор
                Date - дата изменения
                Type - тип изменения
                Rel - ссылка на новое значение
                Cause - ссылка на рубрикатор причин
                Note - коментарии

              Спасибо за столь развернутый ответ. Обязательно использую. Но откуда эти строки кода? Какой язык? Изучал С++, РНР, SQL, но эти не знакомы :(
              Сообщение отредактировано: flintpit -
                Это не "язык". Это описание структур в принципе. А на чём его реализовать - дело десятое.
                  Проанализировав множество советов на различных форумах, пришел к решению строить простейшую базу в МS Access. В качестве теории выбрал Хомоненко «Базы данных» (2004), по которой учили в универе, знакомый текст лучше вспоминается, да и сама книга написана на основе зарубежной литературы. В помощь для разъяснения сложных вопросов взял Дейта «Введение в системы баз данных» (2005), которого все рекомендуют, и Крёнке «Теория и практика построения баз данных» (2003) из вызывающей доверие серии «Классика computer science» издательства Питер.
                  В качестве практического руководства по MS Access взял Сеннова и Гурвица.
                  Всем спасибо за ответы!
                    Цитата flintpit @
                    пришел к решению строить простейшую базу в МS Access
                    Зря... Акцесс хорош для домашней библиотеки. Но никак не подходит для твоего случая.
                    ЗЫ - в его SQL-коде даже комментарии нельзя вводить!!!
                    Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна).
                    ---
                    ЗЗЫ - а в части обмена - Oracle DataPump в помощь. Не так быстро, как замена одного ACCDB на другой, но и не так критично по времени. У тебя не СУБД реального времени (не телефонная компания)!
                    Сообщение отредактировано: #SI# -
                      Цитата #SI# @
                      Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна).

                      А теперь расскажи, как с твоим советом предлагается воплощать исходное требование
                      Цитата flintpit @
                      БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью.

                      Причём не в части переноса данных (DataPump с этим действительно справится), а в части переноса сервера БД, без которого нихренашеньки не станет работать. Не припоминаю я существования у них встраиваемого сервера что-то... да и для невстраиваемого аппаратная конфигурация должна быть, скажем прямо, нетривиальная, что в реалиях ВС РФ наличествует далеко не везде...
                        Akina, не думаю, что речь идёт о БД командира отделения. А вот на уровне части (военкомата етс...) - твой вопрос несущественен.
                        ЗЫ - хотелось бы знать, что реально написано в ТЗ на разработку.
                          #SI#
                          Я думаю, что это личная (возможно, и общественная, но никак не официальная) инициатива низовых работников. Которые задолбались работать в бумаге. Более того - почти убеждён, что это так. И, следовательно, ни о каком ТЗ речи не идёт. Зато идёт речь о максимально простых и доступных, в т.ч. по освоению и углублённому изучению, средствах разработки - причём строго локальных, а не визуально-облачных. И в этом смысле Access как бы не в тройке (ну или во всяком случае в группе) лидеров.
                            Как "карманный" вариант, думаю, потянет такое решение: Using MySQL on a Raspberry Pi. Конечно на старте будет непросто, нужно будет много чего осваивать параллельно, кроме SQL и проектирования реляционных БД. Но, по идее, может получится конфетка. Этакая биг-флэшка с дисплеем :)
                              Цитата Akina @
                              <...ППКС...>причём строго локальных, а не визуально-облачных. И в этом смысле Access
                              есть почти у всех нахаляву. В составе пиратского офиса :D . С этим - согласен.
                              Но для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО!

                              Добавлено
                              Цитата JoeUser @
                              Этакая биг-флэшка с дисплеем
                              Идеальный вариант. Но, похоже, ТС этим будет заниматься в свободное от основной работы время... :(
                                Цитата #SI# @
                                для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО!

                                Категорически не согласен.
                                На моей памяти (лет эдак 15 назад было) эксперт-криминалист самостоятельно, практически в одиночку, создал на Аксессе вполне работоспособную БД для фиксации, накопления и анализа результатов экспертиз. В начале работы он с трудом использовал Эксель. Через 2 года у него приложение было полностью работоспособно. Среднее количество атрибутов на первичную сущность - штук 30-40, количество типов первичных сущностей - порядка 20, количество выходных форм - с полсотни, автоматизированных обработок штук 5...
                                Глаза боятся, а руки - делают. И даже если в конце концов ТС придёт к выводу, что Access как инструмент для его задачи не очень удачен, он успеет накопить достаточные знания и опыт, чтобы реализовать следующую версию на более "продвинутых" средствах.
                                  Можно вспомнить Visual FoxPro для начала пойдет (своя среда разработки и своя база).
                                  Также если указать на какой оболочке будет писаться интерфейс то можно подобрать и базу.
                                  Сообщение отредактировано: Bas -
                                    Цитата Akina @
                                    На моей памяти (лет эдак 15 назад было)
                                    Ещё раз, члено и раздельно - НЕ НАДО заниматься ювелирным искусством при помощи кувалды. 15 лет назад - согласен, тогда и выбирать было не из чего.
                                    Почему я Оракл рекомендовал - только потому, что можно работать на полноценном БЕЗ ЛИЦЕНЗИИ движке с безграничными возможностями программирования.

                                    Добавлено
                                    Цитата Bas @
                                    Можно вспомнить Visual FoxPro
                                    Можно вспомнить Клиппер :D :D :D ! Сорри за флуд...
                                    Сообщение отредактировано: #SI# -
                                      Кстати, вспомнилось. Мой клиент-банк использует Adaptiv Server Anywhere, типа какой-то из встраиваемых предков SyBASE. О качестве ниче сказать не могу, но ... пользуюсь как юзер часто :) А вообще, повторюсь, SQLite, имхо, для топика был бы идеальным решением. Выбор конечно же за ТС.
                                        Цитата JoeUser @
                                        SQLite, имхо, для топика был бы идеальным решением.
                                        Не работал, не знаю. Но ТВОЁ мнение - :thanks: !
                                          Господа, забыл упомянуть. В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ есть только такие СУБД: Oracle Database, DB2, PostgreSQL, Interbase, MS SQL Server, ADABAS, ну и MS Access с 1Cкой. Всё, других в Перечне нет. И чтобы его туда официально добавить в заявке необходимо обосновать, почему его необходимо туда включить.
                                          Из приведенных выше что лучше выбрать для слабеньких и средненьких машин, не соединенных сетью?

                                          Добавлено
                                          Цитата #SI# @
                                          Но, похоже, ТС этим будет заниматься в свободное от основной работы время... :(

                                          Так оно и есть :(
                                            Цитата flintpit @
                                            В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ есть только такие СУБД: Oracle Database, DB2, PostgreSQL, Interbase, MS SQL Server, ADABAS, ну и MS Access с 1Cкой. Всё, других в Перечне нет.

                                            В списке есть Interbase? и при этом нет Firebird? странненько... проверьте.

                                            Цитата flintpit @
                                            Из приведенных выше что лучше выбрать для слабеньких и средненьких машин, не соединенных сетью?

                                            Строго IMHO.
                                            Если приложение планируется на высоком языке - Interbase embedded. Или Firebird embedded, если выяснится, что его таки можно.
                                            Иначе MS Access.
                                              Цитата flintpit @
                                              В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ

                                              Без обид, но сей Перечень составлял краб одной клешней. Это надо додуматься разрешить использование ПО с закрытым кодом! Они бы еще M$ Windows на свои крылатые ракеты разрешили. Вон военные из Пендостана для обеспечения надежности и безопасности вообще создавали и стандартизировали под себя ЯП (язык Ада).

                                              Я думаю, стоит сперва пободаться, и попробовать включить нужное тебе в перечень (SQLite, MySQL). А уже по результатам выбирать из возможного. И второй момент, вот очередной раз подумалось... В требованиях к разработке указывается необходимость мобильности. А что если просто запилить LiveUSB с каким нить *nix'ом? Как обоснование, указать - полностью открытый исходный код, полностью бесплатная лицензия на использование. Если такое прокатит - будет просто праздник, и никаких непоняток. На LiveUSB поднимается любой из возможных SQL-серверов, клиентская часть пилится на Qt5/C++. Документации, примеров, сообществ просто валом.
                                                Цитата Akina @
                                                В списке есть Interbase? и при этом нет Firebird? странненько... проверьте.

                                                Возможно имеется в виду InterBase Open Source Edition. С другой стороны Firebird это клон InterBase, а клоны перечислять не обязательно.
                                                Цитата flintpit @
                                                Из приведенных выше что лучше выбрать для слабеньких и средненьких машин

                                                IMHO. С большими оговорками, Interbase,MS Access, 1C (ранние версии).
                                                Цитата flintpit @
                                                не соединенных сетью?

                                                Все перечисленные СУБД ориентированы на многопользовательский режим, работа в сети.
                                                Цитата JoeUser @
                                                (язык Ада)

                                                Второй язык который начал изучать после Fortran 4 на таких
                                                Прикреплённый файлПрикреплённый файлpunchcard.jpg (103,82 Кбайт, скачиваний: 682)
                                                носителях, даже книжка есть где-то на полках.
                                                PS Можно использовать не СУБД, а "плоские" базы данных Dbase например.
                                                Цитата #SI# @
                                                Можно вспомнить Клиппер!

                                                :good:
                                                  Цитата Bas @
                                                  С другой стороны Firebird это клон InterBase, а клоны перечислять не обязательно.

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

                                                  Цитата JoeUser @
                                                  стоит сперва пободаться, и попробовать включить нужное тебе в перечень (SQLite, MySQL).

                                                  Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально...

                                                  Цитата Bas @
                                                  Можно использовать не СУБД, а "плоские" базы данных Dbase например.

                                                  Я бы на самом деле ещё предложил в части "плоских" подумать про XML. Во-первых, в нём можно хранить достаточно сложные схемы, в т.ч. и нереляционные, во-вторых, там же можно хранить и скрипты обработки и отображения. Ну а компоненты для базовой работы с XML (в т.ч. и как с источником данных, ADO/ADOX) имеются в ОС без дополнительных "вливаний".
                                                    Цитата flintpit @
                                                    что лучше выбрать для слабеньких

                                                    Слабенькие это какие на Z80 или на i286 (двойка)?
                                                      Цитата Akina @
                                                      Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально...

                                                      no pain, no gain ;)
                                                        Цитата Bas @
                                                        Цитата flintpit @
                                                        что лучше выбрать для слабеньких

                                                        Слабенькие это какие на Z80 или на i286 (двойка)?

                                                        Нет, вроде старые Пни.

                                                        Добавлено
                                                        Цитата Akina @

                                                        Цитата Bas @
                                                        Можно использовать не СУБД, а "плоские" базы данных Dbase например.

                                                        Я бы на самом деле ещё предложил в части "плоских" подумать про XML. Во-первых, в нём можно хранить достаточно сложные схемы, в т.ч. и нереляционные, во-вторых, там же можно хранить и скрипты обработки и отображения. Ну а компоненты для базовой работы с XML (в т.ч. и как с источником данных, ADO/ADOX) имеются в ОС без дополнительных "вливаний".

                                                        В чём разница плоских БД и имеющейся у меня книги в Excel?

                                                        Добавлено
                                                        Цитата Akina @
                                                        Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально...

                                                        Так и есть. Чтобы получить разрешение на локалку между двумя внутри одного кабинета, необходимо доказать московскому командованию, что без этой локалки воинская часть не способна выполнить боевую задачу. Назовут плохим словом и прикажут делать по-старинке.
                                                        Сообщение отредактировано: flintpit -
                                                          Ехель - это вообще НЕ база данных!
                                                            Цитата flintpit @
                                                            В чём разница плоских БД и имеющейся у меня книги в Excel?

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

                                                            Опять же - различайте систему хранения данных и систему их обработки.
                                                              Цитата flintpit @
                                                              В чём разница плоских БД и имеющейся у меня книги в Excel?

                                                              Данные хранятся отдельно, бизнес-логика и интерфейс обработки отдельно в коде. Нет прямого доступа к данным.
                                                                Цитата Bas @
                                                                Данные хранятся отдельно, бизнес-логика и интерфейс обработки отдельно в коде.

                                                                Ну вообще-то это верно для всех систем хранения данных, включая и SQL-серверы - код, даже SQL-код обработки в форме ХП/ПФ/UDL, формально полностью отделён от данных. Только XML в этом частично отличается от остальных - там бизнес-логика и интерфейс могут являться блоками данных, пусть и особого формата (впрочем, этим практически никто не пользуется даже на промышленном уровне).
                                                                  Цитата Akina @
                                                                  формально полностью отделён от данных

                                                                  За исключением хранимых процедур. Они неуниверсальны, как правило. И "работают" с предопределенными моделями, реализованными в виде совокупности таблиц БД. Иными словами, проблемно-ориентированный код. Не?
                                                                    Так любой код на сервере создаётся для вполне конкретного набора данных. Не?
                                                                      Цитата JoeUser @
                                                                      За исключением хранимых процедур. Они неуниверсальны, как правило. И "работают" с предопределенными моделями, реализованными в виде совокупности таблиц БД. Иными словами, проблемно-ориентированный код. Не?

                                                                      Нет. Не с той стороны смотришь. ХП не являются данными... да они даже не привязаны к конкретной БД, о чём вообще речь?
                                                                        Приветствую!
                                                                        Столкнулся с таким же вопросом по созданию БД для учета личного состава.
                                                                        Проект получилось реализовать?
                                                                        Можете чем поделиться?

                                                                        С Уважением, Валентин.
                                                                        Сообщение отредактировано: JoeUser -
                                                                          Цитата Akina @
                                                                          С учётом этого настоятельно рекомендую забыть про одноэску.

                                                                          Почему?
                                                                          Вполне посильная задача для 1С.
                                                                            kosten
                                                                            Я не говорил, что одноэс этого не может. А забыть рекомендую потому, что:
                                                                            Цитата flintpit @
                                                                            БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью.
                                                                              Цитата Akina @
                                                                              А забыть рекомендую потому, что:

                                                                              Нет проблем перенести базу 1С с одного компа на другой.
                                                                                Базу - да. А оболочку? её на флешке не утащишь...
                                                                                  Цитата Akina @
                                                                                  А оболочку?

                                                                                  Не вижу проблем поставить ее там где требуется.
                                                                                    Проблема есть. И проблема эта - проблема легитимности софта. К тому же когда речь идёт о ВС, сразу надо настраиваться на откровенно слабые станции, на которых доступные сейчас к приобретению версии 1С тупо не встанут, или будут работать там медленно и печально. А даунгрейд лицензиями 1С вроде как не предусматривается...
                                                                                      Цитата Akina @
                                                                                      К тому же когда речь идёт о ВС, сразу надо настраиваться на откровенно слабые станции

                                                                                      Ты давно был в какой-нибудь в/ч?
                                                                                        Цитата kosten @
                                                                                        Ты давно был в какой-нибудь в/ч?

                                                                                        15-го марта.
                                                                                          Akina, тогда это удивительно. ВС весьма не плохо снабжают техникой.
                                                                                            kosten, снабжают-то часть, может, и хорошо. А вот распределяют - забавно.
                                                                                              Ничего в армии не меняется. Мне видимо еще повезло с компами.
                                                                                              0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                                                                              0 пользователей:


                                                                                              Рейтинг@Mail.ru
                                                                                              [ Script execution time: 0,1128 ]   [ 18 queries used ]   [ Generated: 19.03.24, 06:10 GMT ]