نحوه انجام تاشو پایه چگونه یک پایگاه داده جمع آوری کنیم فرآیند جمع آوری یک پایگاه داده

در این مقاله در مورد الگوریتمی صحبت خواهم کرد که در فرآیندی به نام استفاده می شود پیچش پایه 1c.

پیچیدگی پایه 1c(جمع شدن پایگاه داده 1C) رویه ای است که برای بهینه سازی داده های انباشته شده در پایگاه داده 1C استفاده می شود. پایگاه داده 1C برای بهبود کیفیت تجربه کاربر در حال فروپاشی است.

دلایل فروپاشی پایگاه داده 1C

بیایید از دیدگاه یک مثال عملی به مسئله تئوری فولدینگ پایگاه داده نگاه کنیم. مثلا امروز 14 مارس 2008 است. من با پایگاه داده 1C کار می کنم که از 1 ژانویه 2003 نگهداری می شود. این پایگاه برای پنجمین سال راه اندازی شده است. نگهداری پایگاه داده برای یک برنامه نویس دشوار است (افزایش پیچیدگی سیستم به دلیل افزایش تعداد عناصر). همچنین کار با دیتابیس برای کاربران سخت است (سرعت برنامه).

چگونه می توانید کار خود را با پایگاه داده 1C بهینه کنید؟

برنامه نویس، به طور کلی، به اندازه پایگاه داده اهمیتی نمی دهد، زیرا برنامه نویس نه با داده، بلکه با الگوریتم های پردازش داده کار می کند. مشکلاتی در هنگام کار با یک پایگاه داده بزرگ ممکن است برای برنامه نویسی که پایگاه داده را مدیریت می کند به وجود بیاید، مگر در مواردی که پس از ارسال مجدد یک سند در دوره قبلی نیاز به بازیابی توالی باشد، یا زمانی که لازم است همه اسناد به دلیل ارسال مجدد مجدداً ارسال شوند. به تغییرات در الگوریتم برخی از محاسبات . بنابراین بهینه سازی پایگاه داده معمولا با هدف ارتقای کیفیت کار کاربران پایگاه داده انجام می شود.

ویژگی های کاربردی هنگام کار با داده ها

عملکردهای کاربرانی که با پایگاه داده 1C کار می کنند را می توان به سه گروه تقسیم کرد:

1. ورود داده های اولیه؛
2. تجزیه و تحلیل داده های وارد شده؛
3. برنامه ریزی برای داده های آینده

بیایید گروه های عملکردی کاربران را مرور کنیم.

1. کسانی که داده‌ها را وارد می‌کنند، حتی برای «دیروز» نیز به تراز و گردش مالی نیاز ندارند. بدون ذکر اطلاعات مربوط به ماه گذشته یا سال قبل.
2. تحلیلگران داده به داده های تاریخی نیاز دارند. اما در اینجا باید دقیقاً مشخص کنید که آنها به چه داده هایی نیاز دارند. در ادامه در این مورد صحبت خواهیم کرد.
3. برنامه ریزان داده به نتایج تحلیل تاریخی نیاز دارند. به عبارت دیگر، نیازهای کاربران این گروه نیز نیازمند داده های انباشته شده در دوره های قبل است.

جزئیات داده ها برای جمع آوری پایگاه داده 1c

برای تعیین اینکه چه داده هایی برای تجزیه و تحلیل و برنامه ریزی مورد نیاز است، ابتدا باید جزئیات داده ها را روشن کنید. من از قبل می گویم که جزئیات داده های لازم برای تجزیه و تحلیل و برنامه ریزی کلید حل مشکل فروپاشی پایگاه داده 1C است.

سطوح جزئیات داده در پایگاه داده 1C چیست؟ من می توانم اینها را نام ببرم:

• ارسال به حساب ها در حسابداری.
• ثبت حرکت در حسابداری عملیاتی
• سند.
• گردش مالی در روز (هفته، دهه، ماه، سه ماهه، نیم سال، سال).
• موجودی در ابتدا و انتهای دوره (روز، هفته، دهه، ماه، سه ماهه، سال).

هنگامی که سطح کافی از جزئیات داده لازم برای تجزیه و تحلیل و برنامه ریزی موثر مشخص شد، می توانیم در مورد میزان فشرده سازی داده ها هنگام جمع شدن پایگاه داده صحبت کنیم.

کار با داده ها در یک دوره "فشرده" پس از فروپاشی پایگاه داده 1s

اگر داده ها در یک دوره معین "فشرده" یا "فشرده" شوند، می توان فهمید که مقدار کمی از آن کمتر است. اگر حجم داده ها کاهش یابد، برخی از داده ها برای همیشه از بین می روند.

در صورت نیاز چگونه می توانم به داده های جمع شده دسترسی داشته باشم؟ این یک سوال بسیار مهم است و قبل از جمع آوری پایگاه داده 1C باید به آن پاسخ داده شود.

به عنوان مثال، من دو مورد افراطی را بیان می کنم.

مورد 1: در هر روز در سال 2008، مدیر مالی می خواهد بتواند کارت تفصیلی تسویه حساب های متقابل با خریدار "آلفا" را برای مارس 2005 مشاهده کند.

تحت این شرایط، جمع کردن پایگاه داده 1C غیرممکن است، زیرا جمع کردن (فشرده کردن) داده ها در زیر سطح ارسال (جنبش ثبت نام) غیرممکن است.

یک استثنا را می توان روش کاری در نظر گرفت که در آن پایگاه داده هنوز جمع شده است و در پایگاه داده کاری فقط مانده های ابتدای دوره کاری از داده های دوره فروپاشی شده باقی می ماند. سپس شرکت دارای دو پایگاه کارگری است:

1. یک پایگاه داده فعال که داده های مربوط به عملیات جاری در آن وارد می شود.
2. یک پایگاه داده بایگانی که داده های مربوط به تراکنش های دوره های گذشته را ذخیره می کند.

در عین حال، مدیر مالی، به عنوان مثال، به پایگاه داده دوم دسترسی دارد، که کار با آن در واقع متوقف شد. و مدیر مالی در صورت تمایل می تواند در هر زمان وارد پایگاه داده "قدیمی" شود و تمام داده های مورد نیاز خود را در دوره های قبلی بدست آورد.

مورد 2: مدیر مالی می خواهد در هر روز از سال 2008 بتواند از میزان هزینه های اجاره برای تمام محل های انبار شرکت برای سه ماهه سوم سال 2005 مطلع شود. و او به اطلاعات دقیق تری نیاز ندارد (مثلاً کارت تسویه حساب متقابل با صاحب انبار).

در این مورد، پیچیدگی پایگاه داده 1C به این ترتیب انجام می شود:

1. یک درخواست ویژه گردش مالی را تحت عنوان "هزینه های انبار" با جزئیات بر اساس سه ماهه انتخاب می کند.
2. برای هر سه ماهه دریافت شده در درخواست، یک سند جدید "عملیات" (یا سند ویژه دیگر) ایجاد می شود که در آن مقدار گردش مالی تحت عنوان "هزینه های انبار" وارد می شود. سند ثبت و ارسال می شود.
3. پردازش ویژه همه اسنادی را که داده‌های دوره در حال جمع شدن را تحت عنوان «هزینه‌های انبار» وارد کرده‌اند حذف می‌کند (به‌جز سند ویژه ما که هنگام جمع کردن پایگاه داده ایجاد کردیم).

یک استثنا را نیز می توان روشی در نظر گرفت که در آن پایه فقط با انتقال مانده های ورودی به ابتدای دوره کاری جمع می شود. شرکت دارای دو پایه ("کار" و "قدیمی") است. و مدیر مالی، به عنوان مثال، یک صفحه مخصوص در MS Excel برای استفاده شخصی ایجاد می کند. در این تبلت او تحلیل و برنامه ریزی داده ها را انجام خواهد داد. در جدول او به صورت دستی مقادیر کل شاخص های مالی مورد نیاز خود را برای دوره تجزیه و تحلیل وارد می کند. او داده ها را برای تجزیه و تحلیل از پایگاه داده "آرشیو" می گیرد.

الگوریتم کانولوشن پایگاه داده استاندارد 1C

در بیشتر موارد، تا کردن پایگاه داده رایج تر است.

1. پردازش اسناد جدیدی از نوع "ورود موجودی افتتاحیه" ایجاد می کند.
2. پرس و جو موجودی را برای همه حساب های دفتر، ابعاد دفتر، و سایر ذخیره های داده مربوطه در پایان دوره جمع آوری شده انتخاب می کند.
3. داده های دریافت شده در درخواست در اسنادی از نوع "ورود موجودی اولیه" وارد می شود.
4. سند ذخیره شده و در آخرین روز از دوره فروپاشی پست می شود.
5. تمام اسناد 1C برای دوره سقوط حذف می شوند.

روش هایی برای جمع کردن پایگاه داده 1C

بنابراین، دو راه برای جمع کردن داده ها در پایگاه داده 1C وجود دارد:

1. در یک دوره سقوط، تمام معاملات حذف می شوند و تنها موجودی های اولیه موجود در پایان دوره سقوط در ابتدای دوره کاری وارد می شوند.
2. مانند روش اول، اما در دوره فروپاشی گردش مالی مطابق با شاخص هایی که در حالت فعلی در دوره کاری لازم است، با سطح جزئیات مورد نیاز باقی می ماند. مانده های محاسبه شده با در نظر گرفتن گردش مالی باقی مانده در دوره سقوط به ابتدای دوره کاری منتقل می شود.

بر اساس مواد

با فعالیت پایگاه اطلاعاتی، اندازه آن ناگزیر افزایش می یابد. در شرکت های بزرگ می تواند به 5 گیگابایت در سال یا بیشتر برسد. چنین رشد سریعی می تواند بر عملکرد برنامه و ایمنی داده ها تأثیر بگذارد. هرچه اندازه پایگاه اطلاعاتی بزرگتر باشد، احتمال خرابی هایی که منجر به از دست رفتن داده ها می شود، بیشتر می شود.

چگونه می توان پایگاه داده اطلاعات 1C را با حفظ تمام اطلاعات لازم پاک کرد؟

"فروپاشی پایگاه اطلاعات 1C" به این موضوع کمک می کند - روند پردازش اسناد و ثبت پیکربندی، به شما امکان می دهد اسناد قدیمی و غیر ضروری را حذف کنید. در عوض، چندین سند برای وارد کردن موجودی برای یک دوره معین ایجاد می شود. بنابراین، ما حسابداری را به یک دوره معین "تقاطع" می کنیم.

اهداف اصلی کانولوشن عبارتند از:

افزایش سرعت سیستم

کاهش حجم پایگاه اطلاعاتی

شما باید در مورد پیچیدگی فکر کنید اگر:

1C کند می شود

اندازه بزرگ پایگاه داده 1C (از 5 گیگابایت یا بیشتر)

به روز رسانی 1C زمان زیادی طول می کشد تا تکمیل شود

اسناد سالهای گذشته مایه دردسر است

به عنوان بخشی از پروژه، من با این کار روبرو شدم: چگونه می توان پایگاه داده 1C را هنگام انتقال از 1C:ERP 2.0 به 1C:ERP 2.1 جمع کرد؟

در زمان نیاز به کاهش، شرکت 1C مکانیسم های استاندارد را فقط برای 1C:UT 11 و 1C:BP 3.0 و همچنین برای نسخه های قدیمی تر توسعه داد.

برای توسعه مجموعه، مکانیسم را از 1C:UT 11 به عنوان پایه در نظر گرفتم. انتشار 1C:UT 11 تقریباً همزمان با 1C:ERP 2.0 انجام شد.

مراحل فروپاشی پایگاه داده 1C

پایگاه اطلاعاتی در سه مرحله جمع آوری می شود:

وارد کردن موجودی

حذف داده ها از دوره های گذشته (حذف حرکات و علامت گذاری اسناد برای حذف)

• تطبیق تعادل ها با پایه کاری

وارد کردن موجودی

اسناد ویژه ای برای وارد کردن موجودی در هر پیکربندی ارائه شده است.

پیکربندی 1C:ERP یک همزیستی از چندین زیر سیستم است. هر زیر سیستم از اسناد خود برای وارد کردن موجودی اولیه استفاده می کند.

برای برخی از اسناد برای وارد کردن موجودی در 1C:UT 11، رویه هایی برای پر کردن خودکار مانده ها توسط رجیسترها ارائه شده است.

به عنوان مثال، "کالا در انبارها"، "تسویه حساب متقابل با مشتریان/تامین کنندگان"، "سفارشات مشتری/تامین کننده"، "بسته بندی قابل برگشت"، "نقد نقد")

برای سایر اسناد لازم است رویه های خود را توسعه دهید.

به عنوان مثال، "تسویه حساب با کارکنان"، تا حدی بر اساس ثبت حسابداری، سوابق پرسنلی، دارایی های غیرجاری.

قبل از انتقال موجودی، باید تجزیه و تحلیل کنید که چه داده هایی از پایگاه داده منبع قرار است منتقل شوند. برای اینکه در طول توسعه چیزی را از دست ندهم، تعیین کردم که برای کدام انباشت، حسابداری و ثبت اطلاعات موجودی (داده) در پایگاه داده منبع در تاریخ ورود وجود دارد - گزارشی در مورد مانده ها و حرکات برای همه انباشت، اطلاعات، حسابداری تهیه کردم. ثبت می کند.

• پر کردن مدارک "ورود موجودی اولیه"

برای هر نوع عملیات برای وارد کردن موجودی، من وجود مکانیزمی را برای وارد کردن موجودی در پردازش از 1C:UT 11 تجزیه و تحلیل کردم، که تعیین کرد کدام ثبت این نوع عملیات را جابجا می کند. برای مکانیسم‌هایی که وجود نداشت برای وارد کردن تعادل، من خودم را توسعه دادم.

• پر کردن مدارک "تنظیم ثبت ها"، "انتقال داده ها" و "عملیات (حسابداری تنظیم شده)"

پس از توسعه ورود موجودی ها با استفاده از اسناد استاندارد، مشخص شد که برای برخی از زیرسیستم ها، مکانیسم ها و رجیسترها هیچ سند متناظری برای ورود موجودی وجود ندارد.

به عنوان مثال، مانده‌های ثبت‌های تولید، «سایر دارایی‌ها و بدهی‌ها»، «احکام انتقال»، «صدور دستور»، «تسویه حساب با وجوه برای حق بیمه».

می‌توانید پیکربندی برای وارد کردن موجودی‌ها را با استفاده از رجیسترها (مکانیسم‌های) زیر تغییر دهید یا با استفاده از اسناد، موجودی‌ها را تکمیل کنید:

"انتقال داده" - مناسب برای ثبت سیستم های حقوق و دستمزد و مدیریت پرسنل

"عملیات (حسابداری تنظیم شده)" - مناسب برای موجودی های ثبت حسابداری بر اساس داده هایی که در اسناد "ورود مانده ها" منعکس نشده است.

• "تنظیم ثبت" - مناسب برای زیرسیستم های دیگر.
• طرح های پیچیده برای وارد کردن موجودی

برای برخی مکانیسم‌های 1C:ERP، نمی‌توانید خود را به وارد کردن موجودی در تاریخ جمع‌آوری محدود کنید. این به دلیل این واقعیت است که برای مکانیسم های خاص، داده های کلیدی نه تنها در رجیسترها، بلکه در خود اسناد نیز ذخیره می شوند. اینها اساساً اسنادی هستند که توسط داده های ثبت ارجاع داده می شوند. در پردازش استاندارد ورود موجودی، چنین مکانیزمی برای ثبت سفارشات مشتری طراحی شده است. ماهیت آن به شرح زیر است:

1. باقی مانده مانده های سفارش بسته نشده گرفته می شود

2. اسناد باقی مانده با یک نظر خاص مشخص شده است

3. برای سفارشات نیمه بسته، قسمت جدولی فقط با داده های موجودی در تاریخ جمع آوری مجدد پر می شود

در این صورت ما اسنادی را برای درج موجودی در دفاتر ثبتی مکانیسم سفارش وارد نمی کنیم و اسناد سفارشی که موجودی برای آنها وجود دارد با تبصره خاصی مشخص می شود. چنین اسنادی در مراحل بعدی کاهش حذف نمی شوند.

من از همین مکانیسم برای مدارک پرسنلی استفاده کردم. اسناد کارمندانی که در تاریخ کاهش کار می کردند با یک نظر خاص مشخص شدند.

حذف داده های تاریخی

حذف داده ها در دو مرحله انجام می شود:

حذف حرکات سند

علامت گذاری اسناد برای حذف

هنگام حذف حرکات برای هر ثبت:

1. تمام اسنادی انتخاب می شوند که:

ثبت را تا تاریخ فروپاشی "انتقال" کرد

2. استفاده از مجموع غیرفعال است

3. حرکات برای هر سند حذف می شوند

برای هر نوع سند، فهرستی از اسنادی که حاوی نظر خاصی نیستند ایجاد می شود. آنها برای حذف علامت گذاری شده اند.

بررسی صحت وارد کردن مانده ها با پایگاه داده کار

ابتدا، موجودی ها به طور کلی برای هر ثبت، برای همه منابع (بدون جزئیات بر اساس ابعاد) بررسی می شوند. اگر مقدار کل هر منبع مطابقت داشته باشد، ثبت بعدی را بررسی می کنیم. اگر تفاوتی وجود داشته باشد، ما تعادل های دقیق تر را از نظر اندازه گیری تجزیه و تحلیل می کنیم. شما باید با اندازه گیری هایی شروع کنید که کمترین تعداد مقادیر مختلف را دارند.

به عنوان مثال، برای اکثر دفاتر، ابتدا بعد سازمان مورد تجزیه و تحلیل قرار می گیرد. مشخص می شود که برای کدام سازمان ها اختلاف وجود دارد. در مرحله بعد، داده های دقیق تر برای هر سازمان تجزیه و تحلیل می شود.

اگر سیستم های پیچیده ای مانند 1C: ERP، 1C: UPP، 1C: اتوماسیون یکپارچه، 1C: مدیریت هلدینگ به میزان بیشتری برای اهداف حسابداری استفاده شوند، در این صورت استفاده ناقص یا نادرست از برخی عملکردهای برنامه امکان پذیر است. این به دلیل این واقعیت است که کارمندان خدمات حسابداری کنترل ثبت های حسابداری را انجام می دهند، تنظیمات دستی را با اسناد عملیاتی (حسابداری تنظیم شده) انجام می دهند و داده ها را در ثبت های انباشت مربوطه کنترل نمی کنند.

در 1C:ERP، مبنای عملیات حسابداری، رجیسترهای انباشتگی هستند. عملیات تولید اسناد برای وارد کردن مانده ها بر اساس داده های ثبت انباشت انجام می شود.

در این شرایط، موجودی های وارد شده با رول کردن پایه طبق دفاتر انباشت، با توجه به دفاتر حسابداری، بین پایه جدید و در حال کار متفاوت خواهد بود.

دو گزینه برای حل مشکل وجود دارد:

1. در بانک اطلاعاتی کار، موجودی ها را در رجیسترهای انباشت به ترتیب قرار دهید

2. رویه‌های وارد کردن مانده‌ها را از داده‌های ثبت‌های انباشت به داده‌های ثبت‌های حسابداری بازنویسی کنید (اگر داده‌های ثبت‌های حسابداری داده‌های ثبت‌های انباشت را پوشش می‌دهند). من از روش دوم استفاده کردم.

سازماندهی فرآیند جمع آوری داده ها

برای سازماندهی فروپاشی یک پایگاه اطلاعاتی، معمولاً یک نسخه جداگانه از آن ایجاد می شود و پردازش در آن راه اندازی می شود که عملیات توصیف شده در بالا را انجام می دهد. یک کپی از پایگاه داده به منظور ذخیره داده های قدیمی در یک پایگاه داده جداگانه و ادامه کار در یک پایگاه داده جدید جمع شده ساخته می شود.

اگر زمان پردازش طولانی نبود - از چند ساعت تا چند هفته - همه چیز ساده بود.

مدت زمان فرآیند پیچش بستگی به موارد زیر دارد:

پیکربندی پایگاه داده

زیر سیستم های مورد استفاده

حجم داده های وارد شده قبل از تاریخ جمع آوری

با توجه به طولانی بودن فرآیند، دو مشکل مهم ایجاد می شود:

. تا زمانی که پایگاه داده جدید فروپاشی شده آماده شود، باید حسابداری را ادامه دهید: اسناد را بنویسید، داده های تغییر یافته را محاسبه و ثبت کنید، گزارش ها را ارسال کنید. پس از ایجاد یک پایگاه داده جمع‌شده جدید، کاربران باید تمام اطلاعاتی را که در طی فرآیند جمع‌کردن به پایگاه داده قبلی وارد شده‌اند را در پایگاه داده جدید وارد کنند و همزمان داده‌های جدید را وارد کنند. انجام کارهای جاری علاوه بر این، شما هنوز هم باید ترازهای موجود را در جدید بررسی کنید و پس از اضافه کردن موجودی، عملکرد سیستم را بررسی کنید، زیرا ممکن است خطاهای جمع شدن پایگاه داده پنهان وجود داشته باشد.

2. آزمون سختی پردازش کانولوشن . در مرحله توسعه روش کانولوشن یا نوشتن کد پردازش، هزینه خطا افزایش می یابد. برای مثال، اگر فرآیند کاهش 1 روز طول بکشد، در این صورت فرآیند آزمایش با 10 خطا می تواند 10 روز طول بکشد اگر هر خطا بلافاصله شناسایی نشده باشد، اما پس از هر آزمایش جدید. اگر جمع آوری نه 1 روز، بلکه یک هفته طول بکشد، چه؟ اگر 10 خطا وجود نداشته باشد، بلکه بیشتر باشد چه؟...

برای حل این مشکلات، من از طرح تبادل و پردازش XML Data Upload and Load استفاده کردم.

در پایگاه داده کار، من یک برنامه تبادل اضافه کردم که همه تغییرات را پس از ایجاد یک کپی از پایگاه داده برای جمع آوری ثبت می کند. پس از جمع‌آوری، داده‌های تغییر یافته با استفاده از پردازش «آپلود و بارگذاری داده‌های XML» به پایگاه داده کار منتقل شدند. بنابراین، کاربران مجبور به وارد کردن داده ها به پایگاه داده جدید نیستند.

شناسایی خطاهای کدگذاری معمولاً در مرحله بررسی ترازها رخ می دهد، یعنی. پس از وارد کردن مانده ها و حذف داده های تاریخی. از آنجایی که مرحله حذف بسیار طولانی است و صحت وارد کردن موجودی در اکثر موارد به مرحله حذف بستگی ندارد، آزمایش و اصلاح ورود موجودی ها در یک پایگاه داده سوم جداگانه عملی تر است. در حالی که پایگاه داده جدید در حال انجام فرآیند حذف داده های تاریخی بود، من خطاهای شناسایی شده در پردازش جمع آوری را حذف می کردم و رویه های جمع آوری جدید را نهایی می کردم. پس از اتمام حذف اسناد و حرکات قدیمی، یک پایگاه داده جدید اما با بقایای نادرست آماده کردم. در یک نسخه جداگانه از پایگاه داده کار، اسناد موجودی را ایجاد کردم، تغییرات به طور خودکار در طرح مبادله ثبت شد و با پردازش "آپلود و بارگذاری داده های XML" موجودی های تغییر یافته را به پایگاه داده کار جدید منتقل کردم. وقتی خطاهای جدید شناسایی شد، این عملیات را تکرار کردم. این روش به طور قابل توجهی سرعت توسعه و آزمایش رویه های ورود تعادل را افزایش داد.

پایگاه داده مشتری شامل 1.5 میلیون سند در دوره قبل بود.

مدت عملیات عبارت بود از:

1 ساعت - وارد کردن موجودی

6 روز - حذف حرکات

4 روز - تنظیم علائم حذف

از آنجایی که روند توسعه کاملاً کار فشرده است و مدت مراحل کاهش طولانی است، برای آینده دنباله ای از اقدامات زیر را برای خودم تعیین کرده ام:

1. افزودن طرح تبادل به پایگاه داده کار.

2. ایجاد یک کپی از پایگاه داده - "پایگاه داده جمع شده جدید"

3. اجرای رویه ای در پایگاه داده جمع شده برای حذف تمام داده ها قبل از تاریخ جمع شدن (طولانی ترین عملیات)

4. تجزیه و تحلیل ترازها و توسعه عملیات برای ورود به موجودی

5. تشکیل در یک نسخه جداگانه از روش درج موجودی (با ثبت تغییرات در طرح مبادله)

6. انتقال داده ها برای وارد کردن موجودی از یک نسخه از نسخه کار به "پایگاه داده جدید جمع شده"

7. بررسی تعادل، تکرار مراحل 5،6،7 در صورت لزوم.

نوشتن پردازش کامل کانولوشن پایگاه داده برای 1C:ERP برای بار اول دشوار است، و حتی برای بار دوم باید هر مکانیزم، هر زیرسیستم را از داخل به طور کامل بشناسید، اما هر بار بهتر و بهتر از آب در می آید.

ویژگی roll-up از 1C-IzhTiSi این است که کل محدوده کار در پنجره فناوری مشتری قرار می گیرد - زمانی که هیچ کس با پایگاه داده کار نمی کند.

از بین رفتن پایگاه های اطلاعاتی 1C برای کاهش حجم پایگاه اطلاعاتی و همچنین افزایش عملکرد سیستم استفاده می شود. در طول فرآیند جمع‌آوری، داده‌های منسوخ حذف می‌شوند و موجودی‌ها از تاریخ جمع‌آوری وارد می‌شوند.

تفاوت اصلی بین راه حل 1C-IzhTiS و مکانیسم استاندارد 1C در این است که عملیات تغییر داده ها در کوتاه ترین زمان ممکن انجام می شود، به عنوان مثال، زمانی که اندازه پنجره تکنولوژیکی از 2-3 ساعت تجاوز نمی کند.

اگر یک کاهش کامل را نتوان در یک جلسه انجام داد، این فناوری اجازه می‌دهد که فرآیند در بخش‌هایی انجام شود: هم برای اشیاء فردی و هم برای گروه‌هایی از اشیاء در چندین پنجره فناوری.

چه کسی به مجموعه ای از پایگاه های اطلاعاتی 1C نیاز دارد

برای هر شرکتی که برای مدت طولانی در 1C: Enterprise کار می کند:

• اگر متوجه شدید که سیستم کندتر از حد معمول شروع به کار می کند - تولید گزارش ها زمان زیادی می برد و غیره.
• زمانی که حجم زیادی از اطلاعات منسوخ و نامربوط در پایگاه های اطلاعاتی انباشته شده باشد.

چه زمانی باید جمع شود

کانولاسیون باید در موارد زیر انجام شود:

• حجم پایگاه داده بیش از 50 گیگابایت است.
• رکوردها در پایگاه داده بیش از 5 سال است که نگهداری می شود.
• اندازه پایگاه داده هنگام ایجاد پشتیبان مشکل ایجاد می کند.
• قبل از به‌روزرسانی پیکربندی که برای مدت طولانی به‌روزرسانی نشده است.

سازماندهی فرآیند فروپاشی پایگاه های اطلاعاتی 1C

یک برنامه رول آپ معمولی شامل چند مرحله است:

1. رول نسخه ی نمایشی: 5-10 روز کاری

Demo collapse به شما امکان می دهد اندازه نهایی پایگاه اطلاعاتی جمع شده و زمان لازم برای کل فرآیند را تخمین بزنید و همچنین خطاهایی را که در مراحل بعدی تصحیح می شوند شناسایی کنید. این مرحله هم از طرف ما و هم از طرف مشتری قابل انجام است.

2. بررسی نتایج نسخه ی نمایشی رول آپ: 5 روز کاری

پیچیدگی پایگاه داده 1C 8.2- اقداماتی با هدف کاهش حجم پایگاه داده با جمع آوری و بایگانی داده ها برای دوره گذشته. با گذشت زمان، حجم پایگاه داده، به ویژه در سازمان های بزرگ، به طور قابل توجهی افزایش می یابد.

دلایل زیادی برای فروپاشی پایگاه اطلاعاتی 1C 8.3 وجود دارد:

• مقدار زیادی داده روی دیسک (برای یک پایگاه داده فایل، اندازه بیش از 12 گیگابایت حیاتی است؛ یک روز خوب برنامه به سادگی باز نمی شود).
• به دلیل حجم زیاد، ممکن است عملکرد پایگاه داده کاهش یابد.
• اسناد مربوط به دوره های گذشته یک چشم درد است.

گاهی اوقات، در طی 3-4 سال کارکرد، پایگاه داده 1C به حداقل 4-5 گیگابایت حجم "رشد" می کند.

267 درس ویدیویی را در 1C به صورت رایگان دریافت کنید:

برای خلاص شدن از شر داده های قدیمی و در عین حال از دست ندادن داده های فعلی، لازم است جمع آوری پایگاه داده 1C.

جمع آوری پایگاه داده در 1C چیست؟

جمع کردن یک پایگاه داده 1C یک عملیات معمولی است که شامل حذف اسناد غیر ضروری قدیمی است. به جای اسناد، به عنوان یک قاعده، 1 سند برای وارد کردن موجودی برای یک دوره مشخص تولید می شود. بنابراین، حسابداری در پایگاه داده را به یک دوره معین قطع می کنیم.

چگونه یک پایگاه داده 1C را جمع کنیم

روال جمع‌آوری معمولاً با استفاده از پردازش تخصصی شرکت 1C انجام می‌شود که روی دیسک ITS برای هر دو نسخه 1C 7.7 و 1C نسخه 8 موجود است. با این حال، باید بدانید که جمع‌آوری پایگاه داده با استفاده از پردازش از دیسک ITS فقط با یک پیکربندی استاندارد در غیر این صورت ممکن است خطاهایی ظاهر شوند که بلافاصله قابل مشاهده نخواهند بود. اگر پیکربندی استاندارد ندارید، برای جمع کردن پایگاه داده، بهتر است به .

پردازش کانولوشن خود اساساً مراحل زیر را انجام می دهد:

• سند "درج موجودی" برای تمام حساب ها / ثبت در تاریخ مورد نیاز وارد می شود.
• اسناد را قبل از تاریخ مورد نیاز حذف کنید.

به عنوان مثال: جمع آوری پایگاه داده 1C 8.2 accounting 2.0 طی 3 سال حدود 2-3 ساعت طول می کشد. 1C Accounting 3.0 حدود یک ساعت طول کشید تا در 2 سال تکمیل شود.

پردازش دانلود برای Convolution 1C

برای تاشو، بهتر است آخرین پردازش تاشو برای 1C (7.7 و 8) را از توسعه دهندگان رسمی - 1C، در وب سایت http://its.1c.ru/ دانلود کنید. شما همچنین می توانید پردازش را از توسعه دهندگان شخص ثالث دانلود کنید یا حتی یک نسخه اصلاح شده از عملکرد را از برنامه نویسان خصوصی 1C خریداری کنید.