Comments 41
За кадром остался лишь вопрос - а как вы совмещаете вуз и дополнительную работу, кушать же на что-то надо.
Картинки давайте! :)
Пример работы с Документом, Справочником, Журналом. Тексты триггеров, меняющих физические данные при модификации данных хранимок/вьюх. Работа со ссылочными данными (наприпер: как вы добавляете справочные данные, которых не оказалось в списке выпавшего комбо).
Про процесс модификации структуры расскажите. Как вы переносите новые метаданные из тестовой стстемы в рабочую?
я, можно сказать так, экстремальный программист ) оперирую на живую. Это к вопросу о том, как переношу метаданные. Справочники у меня по сути статические. Плюс менталитет пользователей, скажем так. По этому если и возникает потребность в модификации справочника, то делаю просто в базе руками. Это очень редкое явление. По этому не заморачивался с таким функционалом. Система давно в вебе. Статью писал по памяти. И исходников дельфи версии уже давно нет. Но, как ни странно, все работает.
Ох, я конечно понимаю - "работает, не трогай!". Тем более за вузовскую зарплату! Но упорное использование древних версий дельфи, сервера, компонентов становится чем дальше, тем всё более мрачным подарком тому, кто придёт после Вас.
статья была написана так сказать для затравки. Для плавного перехода на рассказ о том, как я ушел в веб. На данный момент дельфи версия уже в истории
Возможно, зря Вы об этом в статье не упомянули. В текущем виде статьи, по-моему, логично моё удивление - почему человек пользуется версией дельфи, вышедшей в 2002 году, а не версией 2025 года, и почему Вы не заботитесь о будущем Вашего продукта. А теперь оказывается, что этого продукта уже и нет, а я тут о нём переживаю, минуса огребаю. :)
А вопросом кто придет после меня не задаются. Но это дискуссия не для публичной плоскости
Тут прекрасно чуть более чем все 🙂
Ощущение причастности, потому что сам 15-20 лет назад учился в аналогичном вузе с аналогичной атмосферой / аурой / вайбом.
Тот самый win forms в региональной госухе начала тысячелетия, где из-за скукоты и однообразия придумываешь справочник справочников.
Делфи 7 и firebase, застрявшие в пространственно-временном континууме.
Сферический программист 16 летней выдержки из НИИ им. Ленина Государственного Университета им. Ленина города Н-ска (лучше не выходить в современный несущийся на всех парах мир с его сберами, яндаксами и озонами, ИИ-шками, современными технологиями и подходами, алго-собесами в стиле фаанга, удаленки, зарубежной удаленки, больших и сложных проектах меняющие отрасль или даже мир - можно получить удар по психике 😧 )
Запредельная наивность (ведь не с чем сравнить свои 750 таблиц и 2000 хранимок) и ламповость (как будто привет из давно забытого прошлого).
Нетленка и пусть весь мир катится ко всем чертям 🙂. Как вы смогли все это сохранить?
ну по поводу сохранить я скажу так. Уже выше отвечал, что дельфи-версия это уже история. Вся система уже давно перешла в веб. Но это тема для другой статьи ) А про количество таблиц и хранимок это я так - к слову. Не firebase, а firebird ) если он выполняет свои задачи - почему нет
В рамках изложенной автором задачи и выделенных на неë ресурсов все эти "меняющие мир проекты" и прочие микросервисы в микросервисах - бесполезная мишура. Это даже не забивка гвоздей микроскопом, а скорее удаление гланд через анус.
А уж что-что, но алго-собесы академические программисты из университета пройдут намного лучше стандартного объектно-ориентированного быдлокодера из Озона.
Интересный опыт, будем ждать следующую статью!
Вы удивитесь, но в некоторых компаниях, написанное на этом стеке приходится тянуть, поддерживать, развивать до сих пор. У нас отдельное подразделение.
Особая тоска, невозможность переложить FB 2.5 в Линукс из-за хранимое и длл. Тысячи хранимок. Инспектировать, где используются DLL винды, никто не берется.
Наверное, не "хранимки", а "внешние функции"?
...
Крутяк. А мой один проект как-то незаметно на линуксовый сначала Firebird 3.0, а потом и на RedBase 3.0 перекинули. Экспериментаторы чёртовы, а не клиенты. Были бы udf-ки - фиг бы у них что получилось.
Я сперва в проекте базу с 2.0 на 3.0 проапгрейдил (с большим скрипом из-за проблем с юникодом в метаданных), а дальше клиенты уже сами втихую развлекались. Надо было хоть каких-нибудь udf наваять, чтобы не безобразничали.
Берите Lazarus и перекладывайте, там вроде есть компоненты IBX, которые на базе делфевовских компонентов.
1С предприятие 8.... гораздо лучше, иерархические справочники, потому что если к примеру дисциплина количество часов изменилось или оно различное по различным специалтнлчям и наборам обучения, как Вы будете на своей системе что либо автоматизировать на 1С все идет гораздо быстрее
слегка недопонял. Справочник дисциплин это просто плоский справочник.учебный план - ссылается на дисциплину. в учебном плане по всем дисциплинам расчасовки. Каждый новый год - копируешь старый план на новый год. По месте и размерам таблиц это копейки. И никаких тебе проблем с иерархиями. да и не нужны они тут
Конечно, если часы и компетенции не изменились, то можно копировать без проблем, а если часы изменились или компетенции изменились, или литература изменилась, что Вы будете делать тогда. Вот в чем вопрос. Поменять компетенции можно только на новый набор, на старый нельзя, отсюда и необходимость иерархии, и которая обеспечивает 1С.
что в данном контексте имеется ввиду под литературой и компетенциями? 2023 год поступления. условно три дисциплины. первая в первом семестре вторая во втором третья в третьем. ну и контроли так же. человек поступил в 2023 году. Закрепился за этим планом. Идет строго по нему. Добавилась новая дисциплина в план 2023 - переформируется план студента и все. 2024 год поступления. копируется план с 2023. делаешь любые изменения. хоть дисциплину удаляй, хоть добавляй. меняй расчасовку, контроли. человек поступивший в 2024 году будет привязан к этой копии. А по сути самостоятельному плану с годом поступления 2024 года. ни план 2023 не мешает 2024 ни на оборот
Смотрите. Раньше к примеру в наборе 2023 года дисциплина А имела 288 часов и компетенции ОК-1. ОК-2, ОК-3. На набор 2024 года дисциплина А. Стала иметь 216 часов и компетенции ОК-1, ОК-2, ОК-5. Ну и как Вы поступите в этом случае без иерархии, дисциплина вроде одна, а общее количество часов разное, и компетенций на набор 2023 и 2024 года разные. Причем просто заменить одни компетенции на другие нельзя в наборе 2023 гола, ибо учебный план составляется на каждый набор
мы наверно слегка мыслим в разных идеологиях (1с) Дисциплина у меня это просто справочник (PK,NAME) дисциплинами учебного плана они становятся когда их подцепишь к строке плана (planId,disciplinaId_FK, hours,....) Часы и компетенции это не свойство дисциплины. Это свойство строки учебного плана. И у нее же есть свойство (FK) дисциплина. И все работает как часы уже лет 15 )
То есть по Вашему получается что в рабочей программе могут появится одни часы, а в учебном плане другие часы, если часы и компетенции никак не привязаны к дисциплине, но только к строке учебного плана. Ведь в рабочей программе и в учебном плане строки и их нумерация разная. И в образовательной программе то же. Получается что в РПД чисто теоретически могут если следовать Вашей логике, быть одни часы и компетенции, в учебном плане другие часы и компетенции, а в ОПОП третьи часы и компетенции. Так что ли или как
литература, если имеется ввиду РПД привязана к строкам плана. при копировании плана копируются и привязки. Но можно отвязать и привязать литературу в плане 2024 года который является копией 2023 без ущерба последнему
Допустим дисциплина изучается в 1 семестра. В наборе 2023 года использовался учебник 2020 года по дисциплине А. А в наборе 2024 года использовался учебник другого автора но 2024 года. Как Вы в таком случае два учебника 2020 и 2024 года привяжите к ключевому полю дисциплина, для, набора 2023 и 2024 года, если справочник дисциплины у Вас плоский и без иерархии. Вот в чем вопрос
уже выше ответил. Повторюсь. Дисциплина это просто справочник (pk,name) а дисциплина учебного плана это уже строка плана со своим набором атрибутов. И она автономна внутри года поступления. В другом году поступления это другая строка учебного плана со своими значениями атрибутов
Ещё ситуация сложнее становится когда одна и та же по названию дисциплина читается одновременно на разных направлениях подготовки. Вот тут точно без иерархии не обойтись, ибо дисциплина читается одновременно, направления подготовки разные, часы, разные, компетенции разные, а название дисциплины одно. И как Вы обойдетесь тут без иерархии, если ключевое поле для составления учебного плана, РПД, и образовательной программы является дисциплина. Вот в чем вопрос.
вы мыслите в рамках 1с с ее периодическими атрибутами иерархией и прочим. еще раз повторюсь. дисциплина как общая сущность это просто плоский справочник никак не соотвесенный с учпланом. эта дисциплина не имеет никаких часов и прочего. просто потому что это справочник pk,name А атрибутами дисциплина обрастает в строке учплана. вернее дисциплина это оин из атрибутов строки учплана. и условная биология в одном и в другом учплане имеет разную расчасовку. так как это по сути не просто дисциплина а уже часть учебного плана со своими параметрами. которые актуальны только в этом плане и нигде больше Не дисциплина является ключем для составления плана, РПД и прочей ... а СТРОКА УЧЕБНОГО ПЛАНА. у которой есть атрибут дисциплина, часы, контроли и тд. все проще чем кажется на самом деле
Если ключеввм полем является у Вас номер строки учебного плана, а не дисциплина учебного плана тогда возможны ошибки, то есть атрибуты сроки в учебнлм плане и рабочей программе дисциплины могут быть разными, а следовательно возможна ситуация, когда часы и компетенции указанные в учебном плане по той или иной дисциплине будут не совпадать с часами, компетенциями указанными в рабочей программе, ибо атрибуты дисциплины учебнго плана, могут не совпадать с атрибутами дисциплины рабочей программы, а следовательно, в этом случае рабочая программа не будет соотвествовать учебному плану. Вот и всё
Читайте закон об образовании, что такое учебный план. Там чётко сказано, что компетенции, часы, формы контроля, привязываются не к строке учетного плана а к дисциплие (практике, ИГА) как к таковой. Вот и весь сказ
а причем тут закон об образовании и проектирование информационных системы и базы данных? не вижу прямой связи. а то как отражены связи в базе это всего лишь форма реализации. и да, данные в базе можно для анализа и отображения повернуть как угодно. Хочешь смотри от учебного плана. хочешь от дисциплины. Не виду тут особой проблемы.
Как я вуз автоматизировал