PDA

View Full Version : سوال: ذخیره داده با تعداد نا محدود ؟



Modifier
چهارشنبه 17 شهریور 1389, 14:29 عصر
سلام
من تعدادی داده دارم که تعدادش نامشخص هست..
میخوام ذخیرشون کنم..
فکر کنم بهتر باشه از دیتابیس استفاده نکنم...آیا درست میگم ؟
اگه از دیتا بیس باید استفاده کنم.. چطور باید این کار رو رو انجام بدم ؟
اگه از چیز دیگه ای بایداستفاده لطفا راهنماییم کنید...

ممنون.
یاعلی.

pezhvakco
چهارشنبه 17 شهریور 1389, 14:50 عصر
میخوام ذخیرشون کنم..
فکر کنم بهتر باشه از دیتابیس استفاده نکنم...آیا درست میگم ؟
ذخیره کردن یعنی استفاده از یک مکان برای ذخیره حالا می خواد یک فایل متنی باشه یا یک فایل بانک اطلاعاتی .


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

Modifier
چهارشنبه 17 شهریور 1389, 15:14 عصر
ذخیره کردن یعنی استفاده از یک مکان برای ذخیره حالا می خواد یک فایل متنی باشه یا یک فایل بانک اطلاعاتی .


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

جناب حاج آقا من کاری به این تعریفا ندارم که حالا ذخیره کردن یعنی چه !!!!

من احتمال میدم از sql server استفاده نکنم بهتره...البته شاید!

در ضمن این چیزی که من میخوام ذخیره کنم یه موقع فکر نکنید مثل سطوح حسابهای حسابداریه هااااا...که دارای n سطح است...

مصطفی ساتکی
چهارشنبه 17 شهریور 1389, 15:17 عصر
نه دوست عزیز .اینطور نیست که داده ای بخاد ذخیره شه الزاماً بایستی از database استفاده بشه. استفاده از databse در همه نوع serialization پیشنهاد نمیشه در بعضی از موارد دیتا با فرمت های دینامیک ذخیره میشه که در همچین serialization هایی database استفاده نمیشه.
اصولاً خیلی از نرم افزار های تجاری معروف دنیا با حجم بسیار بالایی از داده روبرو هستند ولی لزومی نداره که اونا رو تو database های رایج ذخیره کنند.
علت اول Load سریع اطلاعات و دوم فرمت دینامیک.

devil00x
چهارشنبه 17 شهریور 1389, 16:02 عصر
همونطور که دوستمون گفتن


اصولاً خیلی از نرم افزار های تجاری معروف دنیا با حجم بسیار بالایی از داده روبرو هستند ولی لزومی نداره که اونا رو تو database های رایج ذخیره کنند.
علت اول Load سریع اطلاعات و دوم فرمت دینامیک.

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

pezhvakco
چهارشنبه 17 شهریور 1389, 23:35 عصر
من احتمال میدم از sql server استفاده نکنم بهتره...البته شاید!
در ضمن این چیزی که من میخوام ذخیره کنم یه موقع فکر نکنید مثل سطوح حسابهای حسابداریه هااااا...که دارای n سطح است...
اسمی از پایگاه داده خاصی نبردم ؟
شما برنامه نویسی برنامتون هستین و احتمال همراه با اختیار دارین .
مگه حتما باید برنامه حسابداری باشه که پایگاه داده باستفاده بشه . میگن پایگاه داده یعنی مکانی برای ذخیره و مدیریت داده ها با هر ساختار و حجم .

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

مگه این پایگاه داده های کنونی مانند Access, Sql , Oracle چه طوری کار می کنند . بیشترین دلیل استفاده از این ها مدیریت بهتره اون ها است .

مصطفی ساتکی
پنج شنبه 18 شهریور 1389, 07:17 صبح
شما داده ها رو اگه میشه داخل یک فایل متنی داشته باش و با اون کار کن . فقط در این صورت مدیریت کار یکم مشکل تر ، سرعت کار پایین تر، آسیب پذیری داده بیش تر و ... رخ میده ولی باز هم شما یک پایگاه داد داده .
شما گر در این زمینه تجربه ای ندارید حداقل یه سرچ کوچولو کنید تا بحث قشنگ تر بشه.
یه مثال ساده براتون می زنم تا مسئله روشن شه.
من روی نرم افزار های هوش مصنوعی کار می کنم.ما یه ocr چند زبانه داریم که حداقل برای هز زبان 10 فونت رو پشتیبانی می کنه و قابلیت تشخیص صفحه رو در 360 درجه داره.به فرض می خایم با چندین شبکه عصبی بیام داده های ورودیمون رو train کنیم و اونو یه جا ذخیره کنم مسلماً داده هایی با این حجم بالا رو تو یه database مثل sqlserver ذخیره نمی کنه چرا چون داده هایی موجود در هر table شما آنقدر بالا رفته که در Load مجدد جهت دستکاری داده ها شما آفت سرعت دارید.
database برای راحتی کار لایه ای ایجاد می کند که اگر شما به امکانات موجود به این لایه نیاز ندارید استفاده از اون یعنی بار اضافه تحمیل کردن ولی برای حل مشکل بالا کافی یه کلاس serialization ساده بنویسید و داده ها رو به صورت باینری ذخیره و بازیابی کنید با سرعت بالا.

pezhvakco
پنج شنبه 18 شهریور 1389, 08:49 صبح
شما گر در این زمینه تجربه ای ندارید حداقل یه سرچ کوچولو کنید تا بحث قشنگ تر بشه.
ای به چشم جناب ؟


مسلماً داده هایی با این حجم بالا رو تو یه database مثل sqlserver ذخیره نمی کنه چرا چون داده هایی موجود در هر table شما آنقدر بالا رفته که در Load مجدد جهت دستکاری داده ها شما آفت سرعت دارید.من اسمی از نرم افزار خاصی برای پایگاه داده نبردم . در بحث داده های مانند این ( فایل ها و ... ) معمولا روش هایی دیگری برای ذخیره استفاده میشه (مانند مسیر آدرس و ...)


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

SAASTN
پنج شنبه 18 شهریور 1389, 09:52 صبح
شما در آخر داده ها رو کجا و به چه روشی ذخیره و مدیریت می کنین ؟
خب به احتمال زیاد با یه Stream توی یه فایل.
به نظر من قدرت دیتابیس اصلا توی نگه داری حجم اطلاعات نیست، بلکه توی نگهداری شفاف اطلاعات با پیچیدگی بالا و مدیریت تراکنش هاست. اگه اطلاعات شما پیچیدگی زیاد نداشته باشن، یعنی مثلا 5 تا 10 تا موجودیت مختلف باشن و (این تعداد قابل افزایش چشمگیر نباشه) و همینطور جنس کار پردازشی (و نه تراکنشی) باشه، اون موقع استفاده از دیتابیس اصلا راه بهینه ای نیست و بهتره بریم سراغ فایل های باینری. (البته این نظر شخصیه و شاید بیشتر حسی باشه تا فنی)
شما تصور کنید اگه قرار بود داده های گرافیکی یا صوتی بجای فایل های باینری توی ساختار های دیتابیسی ذخیره بشن چه فجایعی اتفاق میافتاد...
نتیجه این که جنس اطلاعات و وظیفه نرم افزاره که نحوه ذخیره سازی رو روشن می کنه نه حجم اونها. حجم اطلاعات در گام بعدی می تونه ساختار فایل باینری و یا موتور دیتابیس رو تعیین کنه.

مصطفی ساتکی
پنج شنبه 18 شهریور 1389, 10:47 صبح
شما در آخر داده ها رو کجا و به چه روشی ذخیره و مدیریت می کنین ؟مثلاٌ تو نرم افزار های شبیه سازی فرمت فایل خودشونو دارن و داده ها به صورت stream در فایل ذخیره میشن شرکت های بزرگ ORM شخصی خودشون دارن چون در Object ها سفارشی هستند در نتیجه از کلاس پایه Serialization توشون گنجونده میشه تا همه کلاس مشتق شده نیز این قابلیت رو داشته باشند. هر کلاسی Archive خودش داده مربوطش رو store و load میکنه .یه flag رو بعنوان flag ورژن ذخیره می کنند تا فایل پروژه با ورژن های مختلف تداخل نداشته باشه.
شما تا حالا نرم افزاری رو دیدید که فایل پروژه اش رو تو database ذخیره کنید . اگر اینکار تو اون نرم افزار صورت گرفته نرم افزار استاندارهای لازم رو نداره یا اینکه اصلاً براش سرعت و چگونگی ذخیره سازی مهم نیست.
مثلاً در مواردی که اینکار ممکنه صورت بگیره( اون هم باز صحیح نیست) نرم افزاری جانبی که دیتای نرم افزار دیگری رو تهیه میکنه(engine interface).چون این نرم افزار های سرویس دهنده هیچ وقت دست کاربر نمیره و تیم برنامه نویس از اون استفاده می کنه برای راحتی کار از یه مقدار زمان می گذرن تا کار رو راحت تر انجام بدن با توجه به قابلیت databse تو navigation و view و edit و ... به اونا میده. البته در نرم افزار تجاری بزرگ بازهم از روش Serialization استفاده می کنن .

pezhvakco
پنج شنبه 18 شهریور 1389, 12:31 عصر
ذخیره داده با تعداد نا محدود ؟
این متن اصلی است .


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


مثلاٌ تو نرم افزار های شبیه سازی فرمت فایل خودشونو دارن و داده ها به صورت stream در فایل ذخیره میشن شرکت های بزرگ ORM شخصی خودشون دارن چون در Object ها سفارشی هستند در نتیجه از کلاس پایه Serialization توشون گنجونده میشه تا همه کلاس مشتق شده نیز این قابلیت رو داشته باشند.
اگه اسم اون شرکت ها رو با منبع اطلاعاتون را بگین تا به اطلاعات من هم اضافه بشه ، پیشاپیش تشکر می کنم .


هر کلاسی Archive خودش داده مربوطش رو store و load میکنه
این Archive ( بایگانی داده) ، store (ذخیره داده) و load (خواندن داده) شما، در کار لازمه و یعنی پایگاه داده . حالا بنا به دلایلی بسیار ، روش کار متفاوت است . ولی فکر نمیکنم این ُُstream تنها روش مناسب باشه .

و اگه این روش کار اون ها هم باشه، هرکس اختیار کار خودش رو داره ولی اون ها هم یک مدیریت خاص برای روش کار مدیریت بر داده هاشون طراحی کردن .


شما تا حالا نرم افزاری رو دیدید که فایل پروژه اش رو تو database ذخیره کنید .
متوجه منظورتون نمی شم . کی همچین چیزی خواصته شده ؟


البته در نرم افزار تجاری بزرگ بازهم از روش Serialization استفاده می کنن .
میشه مثال بزنین ؟
این Serialization (انجام کار پشت سرهم و ترتیب خاص ) ربطی به این نداره پایگاه داده برای نگهداری داده ها از هر نوع استفاده نشه.

SAASTN
پنج شنبه 18 شهریور 1389, 18:19 عصر
این متن اصلی است .
خوب من از این متن متوجه می شم که حجم اطلاعات خیلی بالاست. با این حال یه بار دیگه کل تاپیکو خوندم اما بازم مطلبی ندیدم که این برداشتم رو رد کنه. اگه اشتباه متوجه شدم لطفا Modifier تصحیح کنند.

معمولا برای همچین زمان های اگه خواصته باشم از Sql استفاده کنم، کلمه باینری و یا Blob را جستجو می کنم .
نه منظورم یه چیزی مثل ذخیره تصویر توی دیتابیس نبود. شما فرض کنید که مثلا TPicture بخواد مستقیما با دیتابیس کار کنه. یعنی بجای LoadFromStream یا LoadFromFile یه چیزی مثل LoadFromDataBase داشته باشه.
تازه همون عکس هایی هم که تو دیتابیس ذخیره میشن یا عکسای پرسنلی هستند یا تصاویر اسناد که بصورت BlackAndWhite و بعضا با فشرده سازی توی دیتابیس ذخیره می شن که حجم کمی دارن. تازه تا اینجا هم مشکل حل نمیشه و بعضیا یه Server دیگه فقط مخصوص عکس ها می سازن تا این حجم از اطلاعات کل دیتابیس رو زمین نزنه.
چیزی که می گم اینه که مثلا اگه بخوایم یه دیتابیس بسازیم و توش یه جدول تعریف کنیم به اسم Pixels و توی اون فیلدهای X, Y, Red, Green, Blue تعریف کنیم تا بتونیم اطلاعات یه تصویر رو نگهداری کنیم خیلی کار منطقی ای نیست.

pezhvakco
پنج شنبه 18 شهریور 1389, 18:42 عصر
شما فرض کنید که مثلا TPicture بخواد مستقیما با دیتابیس کار کنه. یعنی بجای LoadFromStream یا LoadFromFile یه چیزی مثل LoadFromDataBase داشته باشه.
روش خواندن داده ها با هر ساختاری بستگی به برنامه نویس داره و اونه که راهه مناسب تر رو انتخاب میکنه .برای مثال : این طور نیست که اگه من در طراحی پایگاه داه و یا کد نویسی برنامه اشتباه کردم، تمام پایگاه داده Sql و مدیریت داده اون رو زیر سوال ببرم .


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


چیزی که می گم اینه که مثلا اگه بخوایم یه دیتابیس بسازیم و توش یه جدول تعریف کنیم به اسم Pixels و توی اون فیلدهای X, Y, Red, Green, Blue تعریف کنیم تا بتونیم اطلاعات یه تصویر رو نگهداری کنیم خیلی کار منطقی ای نیست.
حرف درست جواب نداره . ولی اگه چند راه اشتباه است دلیلی بر نبود راه درست نیست .

مصطفی ساتکی
جمعه 19 شهریور 1389, 08:37 صبح
دوست عزيز يعني اين همه توضيح داديم واضح نبود.
مثلاً نرم افزار Auto CAD به نظر شما فايلش رو توي database ذخيره کنه و براي هر لايسنسي که ميخاد نصب بشه يه database هم نصب بشه اين منطقي.
مثلاً نرم افزار maya و Max بيان فايل پروژشون رو توي database ذخيره کن و هر شرکتي که خواست گيم بنويسه بياد اول چند تا Database تو سيستم طرف نصب کنه تا گيم اجرايي شه.
شرکتي صاحب نام و بزرگ فايل رو در ابتداي طراحي کردن و بعد ها با کم و زياد کردن اون فايل ها چه در header و چه در محتوا به عنوان فايلي استاندار در اومده.
براي نمونه ميگم تو يه نرم افزار که خودم مشغول طراحيش بودم اينقدر طيف داده ها و حتي relation بينشون زياده ولي ما نميايم object هامونو تو database ذخيره کنم .
Object اصلي طوري طراحي ميشه که قابليت serialization داره و کلاس object هاي موجود در پروژه از اين Object به ارث مي برند در اين کلاس يه متد archive به صورت virtual تعريف ميشه و همه کلاس ناشي شده از اين کلاس archive مربوط به خودشونو override مي کنند.
اين ساختار رو به صورت يه فرمت استاندار تعريف مي کنيم سپس همه افراد درگير پروژه طبق همين استاندار باهاش کار مي کنن.
اين دليلش هم کامل مشخصه .دلفي اينقدر کارها رو راحت کرده حتي برنامه نويس در بعضي شرايط راهها درست تر به فکرش نمي رسه.استفاده ار database شرايط خاص خودشو مي طلبه که دوستان توضيح دادند.

BORHAN TEC
جمعه 19 شهریور 1389, 12:08 عصر
زیاد وقت نداشتم تاپیک رو کامل بخونم. ولی در کتاب Delphi 6 Developers Guide یک مثال داره که یک فایل صوتی Wav رو در دیتابیس قرار میده و در موقعی که نیاز به اون داره اون رو در یک Stream میریزه و پخشش می کنه. (اگه اشتباه نکنم در فصل هفتم کتاب بود؟!)

pezhvakco
جمعه 19 شهریور 1389, 20:43 عصر
دوست عزيز يعني اين همه توضيح داديم واضح نبود.
از هموتون متشکرم .

مثلاً نرم افزار Auto CAD به نظر شما فايلش رو توي database ذخيره کنه و براي هر لايسنسي که ميخاد نصب بشه يه database هم نصب بشه اين منطقي.
مثلاً نرم افزار maya و Max بيان فايل پروژشون رو توي database ذخيره کن و هر شرکتي که خواست گيم بنويسه بياد اول چند تا Database تو سيستم طرف نصب کنه تا گيم اجرايي شه.

ذخیره داده با تعداد نا محدود ؟
این نوع نرم افزارها، دارای داده های محدود از نظر تعداد و تقریبا یکسان از نظر ساختار هستند و بنا به کارایی از پایگاه داده جدا استفاده نکردن .
این نوع دادههایی که روش استفاده و زمان آن مشخص است و پیچیدگی ساختاری خاصی در مراحل بعدی مانند گزارش گیری، تغییرات داده ایی و ... نداردند، نیازی به برنامه های مدیریتی پیشرفته ای هم ندارند .
اگر هم می خواست از پایگاه داده استفاده کنه، لازم نبود چند database (پایگاه داده) داشته باشه .

حالا اگه نرم افزار ساده آمار و مدیریتی دانشگاهی، مدیریت یک جشنواره عکس با حدود 5000 نفر شرکت کننده و 5 عکس برای هر نفر و یا مانند این ها می خواستند این روش کار (همون اتوکد، بازی ها و ...) رو در پیش بگیره، نتیجش چی میشد رو من نمی دونم ؟


شرکتي صاحب نام و بزرگ فايل رو در ابتداي طراحي کردن و بعد ها با کم و زياد کردن اون فايل ها چه در header و چه در محتوا به عنوان فايلي استاندار در اومده.
براي نمونه ميگم تو يه نرم افزار که خودم مشغول طراحيش بودم اينقدر طيف داده ها و حتي relation بينشون زياده ولي ما نميايم object هامونو تو database ذخيره کنم .
Object اصلي طوري طراحي ميشه که قابليت serialization داره و کلاس object هاي موجود در پروژه از اين Object به ارث مي برند در اين کلاس يه متد archive به صورت virtual تعريف ميشه و همه کلاس ناشي شده از اين کلاس archive مربوط به خودشونو override مي کنند.
اين ساختار رو به صورت يه فرمت استاندار تعريف مي کنيم سپس همه افراد درگير پروژه طبق همين استاندار باهاش کار مي کنن.
شما بنا کار از تابع ها . کلاسهای تو در تو ( همون serialization ) استفاده کردین ولی داده های شما نه ساختار داده اطلاعاتی داره، نه تعداد نا محدود، نه لزومی به تغییرات بعدی، نه گزارش گیری های خاص و ... کار هایی این قبیل برای سایر داده های آماری.
و شما بنا به برنامه و ساختار کاری اون (relation (پیوند های اجزا و کلاسها )، serialization ( ترتیب های کاری و فواخوانی کلاس ها)، archive به صورت virtual ( نگهداری مجازی کلاسها و روش کار ) و ... ) از روش خودتون رفتین . درست و اشتباه بودنش هم با خودتون است .


اين دليلش هم کامل مشخصه .دلفي اينقدر کارها رو راحت کرده حتي برنامه نويس در بعضي شرايط راهها درست تر به فکرش نمي رسه.استفاده ار database شرايط خاص خودشو مي طلبه که دوستان توضيح دادند.
خوبه میگین راه ها نه راه ؟ اگه یک روش جواب نداد یا جواب داد حتما بدترین یا بهترین نیست ( فکر برنامه نویس در حال رشد است ).
اگه بگم استفاده نکردن از پایگاه داده و امکانات اون شرایط خاص خودشو داره به نظر من بهتره .