Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[54.224.52.210] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Доброго времени суток, уважаемые форумчане!
Я работаю Вооруженных Сил РФ. Учет личного состава ведётся на бумажных носителях. Для автоматизации учета хочу создать базу данных, удовлетворяющую следующим требованиям: 1. У военнослужащего имеется около 90 параметров (учетных данных). 2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д. 3. Хранение записей по нарастающей хронологии, т.е. хранить сведения обо всех детях, датах и номерах приказов о присвоении званий, назначении должностей, периодах службы и т.д. 4. Возможность вывода любых форм (отчетов) в различных комбинациях параметров (учетных данных) и подсчёт всевозможной статистики. 5. Вывод форм (отчетов) в документы MS Word и Excel. 6. БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью. Вопросы: 1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное? 2. Возможно ли реализовать требуемую БД в MS Access или 1С? 3. Какую литературу посоветуете по реализации моей БД? Заранее спасибо. Прошу прощения, если ошибся в терминах. БД изучал в университете 5 лет назад. |
Сообщ.
#2
,
|
|
|
Цитата flintpit @ Реляционную, объектно-ориентированную или что-то иное? Реляционную + объектно-ориентированную. Цитата flintpit @ 2. Возможно ли реализовать требуемую БД в MS Access или 1С? Можно, но как быть с Цитата flintpit @ но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры Одно из требований это установленный офис и 1С. Цитата flintpit @ 2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д. Дети это такие-же физ лица что и родители только у них должен стоять признак что они дети (отдельная таблица). Точно также и родственники военнослужащего, тети ,дяди и остальные кузины и ..... Если отец и мать тоже военнослужащие и у них общие дети, вы же не будете вводить одного и то же ребенка дважды. Достаточно дать ссылку на физ.лицо и установить признак ребенка. Добавлено Так и с остальными структурами, типа место жительства, образования и тд и тп |
Сообщ.
#3
,
|
|
|
Поставленная задача на самом деле требует не столько внимания к организации хранения данных (все озвученные данные можно хранить хоть в plain text или там XML, это несильно скажется на производительности с учётом прогнозируемых объёмов данных), сколько к интерфейсной части (создание необходимых обработок и генерации выходных форм, в т.ч. экспортируемых).
С учётом этого настоятельно рекомендую забыть про одноэску. MS Access в принципе неплох - но возникнут озвученные выше проблемы с необходимостью наличия установленного офиса, причём именно в Проф версии, ибо в стандарте Акса тупо нет, плюс определённые сложности в связи с отсутствием штатных средств резервирования и наличием ограничений на размер БД (с учётом того, что файл БД одновременно используется и как файл-кэш для материализации промежуточных данных). Однако я бы предложил посмотреть в сторону альтернативных инструментов, которые специально затачиваются именно под создание связки БД+интерфейс, но при этом сами портабельны (только интерфейсный обработчик либо комплекс с БД) и содержат более вменяемый встроенный сервер БД. Например, типа MyVisualDatabase (она бесплатна для некоммерческого использования). |
Сообщ.
#4
,
|
|
|
Сперва небольшое отступление. Последние 2 с половиной года разрабатывал АРМ центра социального обслуживания населения. Как оказалось впоследствии, именно грамотное построение структур учета - основной головняк разработки. Не последующие регистрации работ/консультаций/обслуживаний, а именно регистрация и учет граждан... И мне есть чего сказать
Цитата flintpit @ Вопросы: 1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное? Строго реляционную. Потому, как с помощью этого решаемо на 100%, потому как более широко используемо, потому как больше кому будет помочь советом. Цитата flintpit @ 2. Возможно ли реализовать требуемую БД в MS Access или 1С? Возможно. Но с этими двумя на практике не знаком, без комментариев. Цитата flintpit @ 3. Какую литературу посоветуете по реализации моей БД? Сперва искать ликбез по проектированию реляционных БД. Ну а теперь "вкусненькое" ... Типа броне-костюм для строевой подготовки на минном поле 1) "Реляцоинность" данных! Без этого в будущем будут невзгоды и лишения, которые, согласно присяге, вам нужно будет преодолевать. А оно надо вам? Простой пример. Общеупотребимая практика. Для учета граждан создается основная таблица, состоящая из множества полей типа VARCHAR - ФИО, Адрес проживания, иногда и телефон ... Но, и фамилии меняются, и адреса, и телефоны. Со временем. А вам нужно что? Вместо этого собираем наши информационные сущности как из "конструктора". а) Создаем каталог "Описателей", типа: ID - уникальный идентификатор Name - название (используемое в UI), например ФАМИЛИЯ Prompt - короткая подсказка Help - длинный хелп по назначению и способу заполнения Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия б) Создаем каталог "Информационных сущностей", типа: ID - уникальный идентификатор Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО" c) Создаем каталог "Конструкторов Информационных сущностей", типа: ID - уникальный идентификатор Target - ссылка на б) Info - ссылка на a) Cost - желаемый порядок размещения в UI Что в результате? В результате вместо статической структуры, известной на момент сборки - получаем возможность строить нужные нам динамические структуры на момент ввода в эксплуатацию, равно как и во время самой эксплуатации. Нужно нам 90 полей - пожалуйста, нужно 91-е поле, нет проблем - решается администрированием путем создания (при необходимости поля) и "привязки" его к нужной информационной сущности. 2) "Версионность" данных! Вот оно самое: Цитата flintpit @ Хранение записей по нарастающей хронологии Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа: Id - уникальный идентификатор Date - дата изменения Type - тип изменения Rel - ссылка на новое значение Cause - ссылка на рубрикатор причин Note - коментарии Таким образом, наша сборная карточка в последствии будет иметь версионность в виде цепочки изменений. Каждое из которых можно отследить по времени и по исполнителю (об этом ниже). 3) "Журналирование" данных! Каждую операцию нужно журналировать. "Кто-что-когда". Это позволит в будущем делать и анализ работы учетных подразделений, и позволит, при необходимости делать откаты изменений. Ну естественно, не нужно путать принцип "Бритвы Оккама" с неоправданным упрощением информационных моделей. По поводу "движка БД" - посоветую глянуть в сторону SQLite. Сам с ней не работал, но в планах - намереваюсь. Удачи! Добавлено Вдогоночку. Забыл упомянуть про "Отчетность". Давно надумалось неплохое решение - если хранить отчеты, их UI-входные формы и выходные формы, в самой БД. Нет проблем не только для M$ Access! Простой пример. Сам интерфейс пишется на Qt/C++ , а отчеты хранятся в БД в виде VARCHAR, содержащие скриптовые подпрограммы на QtScript. Переработка отчетности совсем не потребует переработки программы. Более того, идеально решается вопрос дистрибуции изменений в отчетности. |
Сообщ.
#5
,
|
|
|
Цитата JoeUser @ Забыл упомянуть про "Отчетность". "Отчетность"- выделить в отдельную тему, так как она многогранна и многолика (по способам хранения, сборки , визуализации)? Если будет обсуждение развиваться. Добавлено Цитата JoeUser @ Сперва искать ликбез по проектированию реляционных БД. поиск по форуму |
Сообщ.
#6
,
|
|
|
Как удалить неправильно написанное сообщение?
Добавлено Как удалить неправильное написанное сообщение? Добавлено Цитата JoeUser @ Вместо этого собираем наши информационные сущности как из "конструктора". а) Создаем каталог "Описателей", типа: ID - уникальный идентификатор Name - название (используемое в UI), например ФАМИЛИЯ Prompt - короткая подсказка Help - длинный хелп по назначению и способу заполнения Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия б) Создаем каталог "Информационных сущностей", типа: ID - уникальный идентификатор Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО" c) Создаем каталог "Конструкторов Информационных сущностей", типа: ID - уникальный идентификатор Target - ссылка на б) Info - ссылка на a) Cost - желаемый порядок размещения в UI 2) "Версионность" данных! Вот оно самое: Цитата flintpit @ Хранение записей по нарастающей хронологии Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа: Id - уникальный идентификатор Date - дата изменения Type - тип изменения Rel - ссылка на новое значение Cause - ссылка на рубрикатор причин Note - коментарии Спасибо за столь развернутый ответ. Обязательно использую. Но откуда эти строки кода? Какой язык? Изучал С++, РНР, SQL, но эти не знакомы |
Сообщ.
#7
,
|
|
|
Это не "язык". Это описание структур в принципе. А на чём его реализовать - дело десятое.
|
Сообщ.
#8
,
|
|
|
Проанализировав множество советов на различных форумах, пришел к решению строить простейшую базу в МS Access. В качестве теории выбрал Хомоненко «Базы данных» (2004), по которой учили в универе, знакомый текст лучше вспоминается, да и сама книга написана на основе зарубежной литературы. В помощь для разъяснения сложных вопросов взял Дейта «Введение в системы баз данных» (2005), которого все рекомендуют, и Крёнке «Теория и практика построения баз данных» (2003) из вызывающей доверие серии «Классика computer science» издательства Питер.
В качестве практического руководства по MS Access взял Сеннова и Гурвица. Всем спасибо за ответы! |
Сообщ.
#9
,
|
|
|
Цитата flintpit @ Зря... Акцесс хорош для домашней библиотеки. Но никак не подходит для твоего случая. пришел к решению строить простейшую базу в МS Access ЗЫ - в его SQL-коде даже комментарии нельзя вводить!!! Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна). --- ЗЗЫ - а в части обмена - Oracle DataPump в помощь. Не так быстро, как замена одного ACCDB на другой, но и не так критично по времени. У тебя не СУБД реального времени (не телефонная компания)! |
Сообщ.
#10
,
|
|
|
Цитата #SI# @ Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна). А теперь расскажи, как с твоим советом предлагается воплощать исходное требование Цитата flintpit @ БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью. Причём не в части переноса данных (DataPump с этим действительно справится), а в части переноса сервера БД, без которого нихренашеньки не станет работать. Не припоминаю я существования у них встраиваемого сервера что-то... да и для невстраиваемого аппаратная конфигурация должна быть, скажем прямо, нетривиальная, что в реалиях ВС РФ наличествует далеко не везде... |
Сообщ.
#11
,
|
|
|
Akina, не думаю, что речь идёт о БД командира отделения. А вот на уровне части (военкомата етс...) - твой вопрос несущественен.
ЗЫ - хотелось бы знать, что реально написано в ТЗ на разработку. |
Сообщ.
#12
,
|
|
|
#SI#
Я думаю, что это личная (возможно, и общественная, но никак не официальная) инициатива низовых работников. Которые задолбались работать в бумаге. Более того - почти убеждён, что это так. И, следовательно, ни о каком ТЗ речи не идёт. Зато идёт речь о максимально простых и доступных, в т.ч. по освоению и углублённому изучению, средствах разработки - причём строго локальных, а не визуально-облачных. И в этом смысле Access как бы не в тройке (ну или во всяком случае в группе) лидеров. |
Сообщ.
#13
,
|
|
|
Как "карманный" вариант, думаю, потянет такое решение: Using MySQL on a Raspberry Pi. Конечно на старте будет непросто, нужно будет много чего осваивать параллельно, кроме SQL и проектирования реляционных БД. Но, по идее, может получится конфетка. Этакая биг-флэшка с дисплеем
|
Сообщ.
#14
,
|
|
|
Цитата Akina @ есть почти у всех нахаляву. В составе пиратского офиса . С этим - согласен.<...ППКС...>причём строго локальных, а не визуально-облачных. И в этом смысле Access Но для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО! Добавлено Цитата JoeUser @ Идеальный вариант. Но, похоже, ТС этим будет заниматься в свободное от основной работы время... Этакая биг-флэшка с дисплеем |
Сообщ.
#15
,
|
|
|
Цитата #SI# @ для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО! Категорически не согласен. На моей памяти (лет эдак 15 назад было) эксперт-криминалист самостоятельно, практически в одиночку, создал на Аксессе вполне работоспособную БД для фиксации, накопления и анализа результатов экспертиз. В начале работы он с трудом использовал Эксель. Через 2 года у него приложение было полностью работоспособно. Среднее количество атрибутов на первичную сущность - штук 30-40, количество типов первичных сущностей - порядка 20, количество выходных форм - с полсотни, автоматизированных обработок штук 5... Глаза боятся, а руки - делают. И даже если в конце концов ТС придёт к выводу, что Access как инструмент для его задачи не очень удачен, он успеет накопить достаточные знания и опыт, чтобы реализовать следующую версию на более "продвинутых" средствах. |
Сообщ.
#16
,
|
|
|
Можно вспомнить Visual FoxPro для начала пойдет (своя среда разработки и своя база).
Также если указать на какой оболочке будет писаться интерфейс то можно подобрать и базу. |
Сообщ.
#17
,
|
|
|
Цитата Akina @ Ещё раз, члено и раздельно - НЕ НАДО заниматься ювелирным искусством при помощи кувалды. 15 лет назад - согласен, тогда и выбирать было не из чего.На моей памяти (лет эдак 15 назад было) Почему я Оракл рекомендовал - только потому, что можно работать на полноценном БЕЗ ЛИЦЕНЗИИ движке с безграничными возможностями программирования. Добавлено Цитата Bas @ Можно вспомнить Клиппер ! Сорри за флуд... Можно вспомнить Visual FoxPro |
Сообщ.
#18
,
|
|
|
Кстати, вспомнилось. Мой клиент-банк использует Adaptiv Server Anywhere, типа какой-то из встраиваемых предков SyBASE. О качестве ниче сказать не могу, но ... пользуюсь как юзер часто А вообще, повторюсь, SQLite, имхо, для топика был бы идеальным решением. Выбор конечно же за ТС.
|
Сообщ.
#19
,
|
|
|
Цитата JoeUser @ Не работал, не знаю. Но ТВОЁ мнение - ! SQLite, имхо, для топика был бы идеальным решением. |
Сообщ.
#20
,
|
|
|
Господа, забыл упомянуть. В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ есть только такие СУБД: Oracle Database, DB2, PostgreSQL, Interbase, MS SQL Server, ADABAS, ну и MS Access с 1Cкой. Всё, других в Перечне нет. И чтобы его туда официально добавить в заявке необходимо обосновать, почему его необходимо туда включить.
Из приведенных выше что лучше выбрать для слабеньких и средненьких машин, не соединенных сетью? Добавлено Цитата #SI# @ Но, похоже, ТС этим будет заниматься в свободное от основной работы время... Так оно и есть |
Сообщ.
#21
,
|
|
|
Цитата flintpit @ В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ есть только такие СУБД: Oracle Database, DB2, PostgreSQL, Interbase, MS SQL Server, ADABAS, ну и MS Access с 1Cкой. Всё, других в Перечне нет. В списке есть Interbase? и при этом нет Firebird? странненько... проверьте. Цитата flintpit @ Из приведенных выше что лучше выбрать для слабеньких и средненьких машин, не соединенных сетью? Строго IMHO. Если приложение планируется на высоком языке - Interbase embedded. Или Firebird embedded, если выяснится, что его таки можно. Иначе MS Access. |
Сообщ.
#22
,
|
|
|
Цитата flintpit @ В Перечне ПО, разрешенного в МО РФ для использования на ПЭВМ Без обид, но сей Перечень составлял краб одной клешней. Это надо додуматься разрешить использование ПО с закрытым кодом! Они бы еще M$ Windows на свои крылатые ракеты разрешили. Вон военные из Пендостана для обеспечения надежности и безопасности вообще создавали и стандартизировали под себя ЯП (язык Ада). Я думаю, стоит сперва пободаться, и попробовать включить нужное тебе в перечень (SQLite, MySQL). А уже по результатам выбирать из возможного. И второй момент, вот очередной раз подумалось... В требованиях к разработке указывается необходимость мобильности. А что если просто запилить LiveUSB с каким нить *nix'ом? Как обоснование, указать - полностью открытый исходный код, полностью бесплатная лицензия на использование. Если такое прокатит - будет просто праздник, и никаких непоняток. На LiveUSB поднимается любой из возможных SQL-серверов, клиентская часть пилится на Qt5/C++. Документации, примеров, сообществ просто валом. |
Сообщ.
#23
,
|
|
|
Цитата Akina @ В списке есть Interbase? и при этом нет Firebird? странненько... проверьте. Возможно имеется в виду InterBase Open Source Edition. С другой стороны Firebird это клон InterBase, а клоны перечислять не обязательно. Цитата flintpit @ Из приведенных выше что лучше выбрать для слабеньких и средненьких машин IMHO. С большими оговорками, Interbase,MS Access, 1C (ранние версии). Цитата flintpit @ не соединенных сетью? Все перечисленные СУБД ориентированы на многопользовательский режим, работа в сети. Цитата JoeUser @ (язык Ада) Второй язык который начал изучать после Fortran 4 на таких Прикреплённый файлpunchcard.jpg (103,82 Кбайт, скачиваний: 683) носителях, даже книжка есть где-то на полках. PS Можно использовать не СУБД, а "плоские" базы данных Dbase например. Цитата #SI# @ Можно вспомнить Клиппер! |
Сообщ.
#24
,
|
|
|
Цитата Bas @ С другой стороны Firebird это клон InterBase, а клоны перечислять не обязательно. Не надо забывать, что мы говорим о людях военных. А у них подход простой. Буквы не те? значит, низзя... и пофиг, что клон. Цитата JoeUser @ стоит сперва пободаться, и попробовать включить нужное тебе в перечень (SQLite, MySQL). Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально... Цитата Bas @ Можно использовать не СУБД, а "плоские" базы данных Dbase например. Я бы на самом деле ещё предложил в части "плоских" подумать про XML. Во-первых, в нём можно хранить достаточно сложные схемы, в т.ч. и нереляционные, во-вторых, там же можно хранить и скрипты обработки и отображения. Ну а компоненты для базовой работы с XML (в т.ч. и как с источником данных, ADO/ADOX) имеются в ОС без дополнительных "вливаний". |
Сообщ.
#25
,
|
|
|
Цитата flintpit @ что лучше выбрать для слабеньких Слабенькие это какие на Z80 или на i286 (двойка)? |
Сообщ.
#26
,
|
|
|
Цитата Akina @ Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально... no pain, no gain |
Сообщ.
#27
,
|
|
|
Цитата Bas @ Цитата flintpit @ что лучше выбрать для слабеньких Слабенькие это какие на Z80 или на i286 (двойка)? Нет, вроде старые Пни. Добавлено Цитата Akina @ Цитата Bas @ Можно использовать не СУБД, а "плоские" базы данных Dbase например. Я бы на самом деле ещё предложил в части "плоских" подумать про XML. Во-первых, в нём можно хранить достаточно сложные схемы, в т.ч. и нереляционные, во-вторых, там же можно хранить и скрипты обработки и отображения. Ну а компоненты для базовой работы с XML (в т.ч. и как с источником данных, ADO/ADOX) имеются в ОС без дополнительных "вливаний". В чём разница плоских БД и имеющейся у меня книги в Excel? Добавлено Цитата Akina @ Люди, которые утвердили этот список, сидят вовсе даже не в соседнем кабинете. И к тому же в принципе не понимают, что утвердили. Думаю, это практически нереально... Так и есть. Чтобы получить разрешение на локалку между двумя внутри одного кабинета, необходимо доказать московскому командованию, что без этой локалки воинская часть не способна выполнить боевую задачу. Назовут плохим словом и прикажут делать по-старинке. |
Сообщ.
#28
,
|
|
|
Ехель - это вообще НЕ база данных!
|
Сообщ.
#29
,
|
|
|
Цитата flintpit @ В чём разница плоских БД и имеющейся у меня книги в Excel? Excel - это табличный процессор. Да, таблицы Excel можно использовать в качестве системы хранения, обращаясь к ним через стандартные драйверы доступа. В этом смысле разница между ним и XML незначительна (имеющиеся ограничения на количество полей-колонок и записей-строк в таблице-листе вряд ли будут достигнуты на старших версиях) - но слишком велик соблазн у пользователя поковыряться непосредственно в данных мимо интерфейса. Не советую категорически. К тому же книги Excel крайне неустойчивы к сбоям. Опять же - различайте систему хранения данных и систему их обработки. |
Сообщ.
#30
,
|
|
|
Цитата flintpit @ В чём разница плоских БД и имеющейся у меня книги в Excel? Данные хранятся отдельно, бизнес-логика и интерфейс обработки отдельно в коде. Нет прямого доступа к данным. |
Сообщ.
#31
,
|
|
|
Цитата Bas @ Данные хранятся отдельно, бизнес-логика и интерфейс обработки отдельно в коде. Ну вообще-то это верно для всех систем хранения данных, включая и SQL-серверы - код, даже SQL-код обработки в форме ХП/ПФ/UDL, формально полностью отделён от данных. Только XML в этом частично отличается от остальных - там бизнес-логика и интерфейс могут являться блоками данных, пусть и особого формата (впрочем, этим практически никто не пользуется даже на промышленном уровне). |
Сообщ.
#32
,
|
|
|
Цитата Akina @ формально полностью отделён от данных За исключением хранимых процедур. Они неуниверсальны, как правило. И "работают" с предопределенными моделями, реализованными в виде совокупности таблиц БД. Иными словами, проблемно-ориентированный код. Не? |
Сообщ.
#33
,
|
|
|
Так любой код на сервере создаётся для вполне конкретного набора данных. Не?
|
Сообщ.
#34
,
|
|
|
Цитата JoeUser @ За исключением хранимых процедур. Они неуниверсальны, как правило. И "работают" с предопределенными моделями, реализованными в виде совокупности таблиц БД. Иными словами, проблемно-ориентированный код. Не? Нет. Не с той стороны смотришь. ХП не являются данными... да они даже не привязаны к конкретной БД, о чём вообще речь? |
Сообщ.
#35
,
|
|
|
Приветствую!
Столкнулся с таким же вопросом по созданию БД для учета личного состава. Проект получилось реализовать? Можете чем поделиться? С Уважением, Валентин. |
Сообщ.
#36
,
|
|
|
Цитата Akina @ С учётом этого настоятельно рекомендую забыть про одноэску. Почему? Вполне посильная задача для 1С. |
Сообщ.
#37
,
|
|
|
kosten
Я не говорил, что одноэс этого не может. А забыть рекомендую потому, что: Цитата flintpit @ БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью. |
Сообщ.
#38
,
|
|
|
Цитата Akina @ А забыть рекомендую потому, что: Нет проблем перенести базу 1С с одного компа на другой. |
Сообщ.
#39
,
|
|
|
Базу - да. А оболочку? её на флешке не утащишь...
|
Сообщ.
#40
,
|
|
|
Цитата Akina @ А оболочку? Не вижу проблем поставить ее там где требуется. |
Сообщ.
#41
,
|
|
|
Проблема есть. И проблема эта - проблема легитимности софта. К тому же когда речь идёт о ВС, сразу надо настраиваться на откровенно слабые станции, на которых доступные сейчас к приобретению версии 1С тупо не встанут, или будут работать там медленно и печально. А даунгрейд лицензиями 1С вроде как не предусматривается...
|
Сообщ.
#42
,
|
|
|
Цитата Akina @ К тому же когда речь идёт о ВС, сразу надо настраиваться на откровенно слабые станции Ты давно был в какой-нибудь в/ч? |
Сообщ.
#43
,
|
|
|
Цитата kosten @ Ты давно был в какой-нибудь в/ч? 15-го марта. |
Сообщ.
#44
,
|
|
|
Akina, тогда это удивительно. ВС весьма не плохо снабжают техникой.
|
Сообщ.
#45
,
|
|
|
kosten, снабжают-то часть, может, и хорошо. А вот распределяют - забавно.
|
Сообщ.
#46
,
|
|
|
Ничего в армии не меняется. Мне видимо еще повезло с компами.
|