FinanceTube.ru

Внесение в базу данных статей ддс | Урок 48

Кол-во просмотров с 22.05.24г. :: 100

Доброго времени суток. Работаем. Сегодня будем вносить в базу данных наконец-то нашу структуру статей. Мы как-то раз это уже, этого коснулись. У нас это было в этом нашем файлике, структура статей и начетность. Вот она. мы называли такое понятие как JSON-строка. кстати, с помощью вот этой самой JSON-строки мы потом будем из 1С закачивать данную систему. я буду показывать как синхронизация делается. и на самом деле вот создаются вот такие вот строчки. И программка 1С, она просто отсылает вот такие вот JSON-строчки в определенное время, они попадают в программу на сервер, расшифровываются, и, соответственно, дальше любой такой вот онлайн-сервис, как мы создаем, пока это сложно назвать онлайн-сервисом, но в любом случае вот такие вот таблички потом возникают благодаря тому, то из 1С все данные поступают в таком виде. Мы сами создадим для себя вот эти внутренние кодовые строки, и нам важно их закинуть в базу. Вчера мы наконец-то добились того, чтобы в новой структуре у нас появился отчет о движении денежных средств. Понятно, что здесь еще есть некоторые нюансы, над которыми стоило бы поработать. И над оформлением, и над тем, как у нас там по меткам мы расписываем, так скажем, вот эти вот потоки данных. Но, так скажем, это уже не так существенно. И поэтому сейчас мы точно можем вот эту вот самую структуру статей, которая у нас вот здесь находится, закинуть ее в базу данных. А какая цель? Цель состоит в том, чтобы у нас была гибкость в том, чтобы мы могли администрировать структуру отчетности. чтобы отчетность могла изменяться, как-то дополняться, корректироваться и так далее. Ну и едем дальше. Значит, еще раз, наша задача — в базу данных, да, внести в базу данных структуру статей. Структуру статей мы уже договорили, что мы ее представляем в виде вот такой вот кодовой, текстовой строки. Значит, нам нужно вот эти кодовые, текстовые строки, их где-то содержать, то есть в базе данных. Под это дело мы сейчас создадим ячейки, и понятно, что поскольку у нас структура статей будет храниться в виде текстовых строк, эти текстовые строки, мы здесь можем увидеть, что они, вообще говоря, могут быть достаточно большими, длинными. то надо это предусмотреть. Нужно предусмотреть, чтобы размер окна, размер текста, который будет у нас находиться в ячейках базы данных, чтобы этот текст мог быть достаточно длинным. И также нам еще нужно дополнительно понять следующий момент. Когда мы здесь вот эту структуру сделали, она у нас отображает или содержит лишь только вот эти вот слова, да, то есть, как-то сказать, ну вот эти словосочетания, которые соответствуют нашим статьям, но в этих кодовых строчках у нас нет вот этих кодов, да, цифровых кодов нет, У нас нет меток. И также, если мы потом дальше будем администрировать вот эту вот всю структуру статей ДДС, то, конечно же, нам бы хотелось еще отображать дату, время внесения каких-то изменений, чего-то еще. И в том числе нам бы хотелось иметь синонимы. То есть если мы, допустим, называли до какого-то момента времени мы называли вот эту статью оплата сырья и материалов, А потом с какого-то, например, со следующего года наше руководство сказало, что слушайте, давайте мы будем не называть оплата сырья и материалов, просто пишите оплата S и M сокращенно. Допустим, появится такая потребность. А почему она, кстати, может появиться? Представьте себе, что все ваше руководство максимально плотно переходит на смартфоны. И внутри смартфона у вас уже нет вот такого вот огромного… Понятно, что каждый из вас на каком-то своем экране это сейчас смотрит, но понятно, что вот я, например, это смотрю на мониторе сейчас, примерно там 26, наверное, дюймов, чтобы видно было хорошо, удобно, комфортно. Вот когда, но если эту таблицу ее в смартфоне смотреть, она будет маленькая, будет очень неудобно. И тогда возникает вопрос того, чтобы вот эти вот самые статьи все, ну как бы их Их название, этих статей, чтобы были минимизированы, чтобы мы не теряли суть, но вот этот, например, столбец был минимальный, единица измерения, здесь не рук, например, можно писать, а ре вот эту вот с этим, ну, как бы, ну, как называется, символ рубля, да, вот такой эр, подчёркнутый снизу вот этой вот ножкой, да. Ну и вот таких вот моментов тут может быть много, да, по которым мы захотим. И понятно, что нам тогда нужно, чтобы... Вот эта вот статья, оплата сырья и материалов, которая у нас будет пронизана в учете факта и так далее, в процессах и регламентах, у нас здесь будет везде оплата сырья. Нам важно будет, чтобы наша система понимала, что если мы вот эту статью переименуем без потери смысла, просто взяли и переименовали. то в этом случае у нас сохранятся все числовые потоки, соответствующие этой статье, которые были до момента переименования. Короче говоря, у нас есть несколько принципиальных требований, к нашей системе, то есть мы должны знать коды, мы должны знать метки, мы должны видеть сами названия, мы должны видеть когда название менялось и его синонимы, и в какой момент эти синонимы туда добавлялись. Вот такая вот ситуация. Соответственно, давайте мы придумаем, как нам тогда эту конструкцию выстраивать. Мне, в принципе, понравились вот эти вот кодовые слова, вот такого плана. Вот эти вот кодовые слова, там где у нас LLL1LL вот с такими двумя и тремя дефисами в начале и в конце, Вполне себе подходит. Нам нужно, чтобы кодовые слова были настолько идиотскими, чтобы, не дай бог, у нас не возникло какой-нибудь статьи здесь, которая бы содержала вот такое кодовое слово. Поэтому чем более дурное какое-то идиотское вот это кодовое слово мы придумываем, тем лучше. тем существенно падает вероятность того, что где-то в названиях у нас такая ерунда возникнет. Потому что мы же будем потом резать по этим кодовым словам и, соответственно, использовать. Понятно, что в какой-то момент вы зададите мне вопрос, а почему вот такую конструкцию JSON-строки мы не используем? Ну, не хочу. Дело в том, что эта конструкция JSON-строки – это конструкция двумерной таблицы на самом деле. А если мы сейчас посмотрим, как мы будем это все собирать, кодовую строчку, она у нас более сложна. То есть кодовая строка, с помощью которой мы будем сейчас кодировать нашу структуру статей DDS, эта система несколько сложнее. И на самом деле, мы с одной стороны сложнее кодируем, с другой стороны резать вот эти вот кодовые строчки гораздо проще, чем если использовать какую-нибудь стандартную кодовую систему. Существуют кодовые системы, понятно, что у нас здесь возникает вопрос конфиденциальности данных. И на самом деле, если мы создаем какую-то свою систему, то с ней на самом деле меньше проблем. Она, во-первых, быстрее работает, чем стандартные кодовые системы. С другой стороны, тот, кто будет стараться понять, как что и чего, Понятно, что с одной стороны саму вот эту структуру можно разложить, но если мы потом еще будем кодировать каким-то другим образом, с помощью других кодовых слов, например, будем кодировать числовые значения, в данном случае там, где у нас учет факта, держать то есть сейчас у нас каждая строчка полностью как бы сидит в базе данных и там что просматривает то есть ровно то как мы видим вот здесь вот нашу таблицу учета факта ровно также она сидит в базе данных а на самом деле чтобы так скажем предусмотреть конфиденциальность здесь можно тоже все вот эти особенно числовые суммовые денежные значения там количественные денежные можно тоже все закодировать вот такими строками но только отдельно и только вы будете знать алгоритм каким образом у нас будут объединяться до соединяться в одну таблицу в одну таблицу будут соединяться статьи и числовые значения. Вот как-то так. Поэтому мы используем какую-то вот такую свою систему. Она не какая-то наша, не выдуманная. Это понятно. Многие математики особенно спокойно к этому относятся. И использовать такой подход — это вполне себе... Это не какая-то моя придумка. Именно по этой причине и существует функция Explode, которая делит вот эту функцию Explode PHP. Мы ее уже проходили. Именно она с этой целью возникла. Такое кодирование каких-то данных, оно очень удобно. Именно данных, у которых есть структура, то есть здесь нетривиальная такая структура. Ну и теперь давайте начнем кодировать. И наша задача следующая. Смотрите, вот эти 1, 2, 3, вот эти кодовые слова, мы их будем также использовать, как и здесь, для отделения блоков. То есть вот это вот единичка, кодовое слово вот это единичка, у нас будет отсекать блоки. Кодовое слово с двоечкой у нас будет отсекать внутренние подблоки уровня 2. А теперь нам необходимо понять, что у нас будет находиться, например, внутри внутри блока, то есть вот у нас идет единичка и потом мы пишем поступление денежных средств это вот это вот название, поступление ds и что мы хотим еще значит сюда впихнуть нам нужно вот это вот поступление денежных средств, поступление ds не только само название, как мы говорили, а нам нужна вот эта конструкция 1.0.0 и кэшло плюс, то есть какая метка. И еще потом дальше, когда у нас пойдет само вот это поступление денежных средств, нам необходимо будет здесь создавать как-то сказать, синонимы. То есть, если администратор системы, допустим, внесет изменения, то это будет называться не поступление ДС, а поступление денежных средств.

Рекомендации

Предшествующее видео

Следующие видео

FinanceTube.ru
С НАМИ ЭФФЕКТИВНЕЕ!
ООО «П++»
ОГРН:1187746086054
ИНН:7728395910
КПП 772801001
Юридический, фактический и почтовый адрес:
117246, г. Москва, Научный пр-д, д.8, стр.7, оф.14
Адрес эл. почты: i@mngmnt.ru
Звоните: +7(985)201-6607
© 2012 - 2024 ООО "П++" (ИНН 7728395910)
Наверх