ساخت یك دیكشنری [بایگانی]

akar_program

دوشنبه 16 آبان 1390, 13:31 عصر

سلام دوستان من میخواهم با ساخت یك دیكشنری شروع كنم جا نمیدونم چطور شروع كنم تا در وسط كار گیر نكنم
من دیتا بیسش دارم فایلی اكسس هست
4 تا فیلد دارد
1 ID
2 English
3 Parsian
4 Kurdish
میخواهم هر سه‌ زبان باهم تخیر بدم
در حالت تایپ هرزبان كلیمه‌ فلتر بشه‌
میلن نویشتم p اون تمام كلیمه‌ های كه‌ با p شروع كردن نیشون بده‌ اگر نویشتم pe انهای كه‌ با pe شروع كرداست
وهم یك دكمه‌ داشته‌ باشد برای خونده‌ن كلیمات تایپ شوده‌
ایا در دلفی میشه‌ نویشته‌ی فارسی و هینگلیسی خوند با یك سدا یانی كامپوننت خاسی دارد
میخواهم دوستا رهنایمون كنن چتور شرع كنم چه‌ كارهای دیگه‌ لازم هست

لطفا هر كسی قبلا كار كرده‌ رهنمای كند

Felony

دوشنبه 16 آبان 1390, 14:11 عصر

اولین ایراد اینکه طراحی بانکتون 100% اشتباه و مبتدیانه هست ، اگر یک کلمه انگلیسی n تا معادل فارسی داشت یا یک کلمه انگلیسی n تا معادل فارسی یا ... چی کار میکنید ؟

3 تا جدول به صورت زیر باید طراحی کنید :

جدول English شامل فیلدهای ID , PE_ID , KU_ID , Title
جدول Persian شامل فیلدهای ID , Title
جدول Kurdish شامل فیلدهای ID , Title

فیلد PE_ID با فیلد ID در جدول Persian ارتباط داره و فیلد KU_ID با فیلد ID در جدول Kurdish ؛ حالا هر کلمه میتونه چندین معنی داشته باشه و مشکلی هم از نظر معنی کردن ندارید ، میتونید انگلیسی رو به کردی ، به فارسی و بلعکس تبدیل کنید و همچنین چند کلمه انگلیسی میتونن یک معنی داشته باشن .

در مورد باقی موارد هم تاپیک های زیادی هست .

یوسف زالی

دوشنبه 16 آبان 1390, 15:09 عصر

سلام.
البته روش جناب تاجیک هم برای کارهای کوچک بسیار کاراست اما در طراحی مشکل ارتباط چند به چند داره.
برای مثال اگر یک کلمه رو به فارسی بنویسید و دنبال تمام معادل های کردی اون باشید..
یا اگر یک کلمه انگلیسی دارای دو معنی باشه اونوقت کلمه redundant می شه.
درست ترش اینه که جداول به این شکل باشند:

جدول کلمات انگلیسی
---------------------------------
ID EnWord

جدول کلمات فارسی
--------------------------------
ID FaWord

جدول کلمات کردی
--------------------------------
ID KuWord

جدول ارتباطات
--------------------------------
ID EnID FaID KuID

که در این جدول آخری مثلا اطلاعات به این شکل می شه: (ID در حقیقت سریال جدول هست و نمی نویسمش)

EnID FaID KuID
------------------
1 0 1
1 0 2
2 0 1
2 0 5
1 1 0
0 1 2
0 1 1
0 5 6

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

در خصوص اون قابلیت تایپ: در رویداد فشرده شدن کلید شما باید هر بار یک کوئری رو فراخوانی کنید که لایک مورد نظر رو فیلتر می کنه و اولیش رو میاره.
در مورد کامپوننت هم برای انگلیسی خود ویندوز این کار رو می تونه براتون انجام بده اما جایی دیده بودم که تلفظ های کلماتی رو که در دیتابیس وجود دارند رو هم در دیتابیس وارد کرده بودند..

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

akar_program

دوشنبه 16 آبان 1390, 16:45 عصر

خیلی ممنون اقا مجتبی + yousijoon لطفا اگر دوستانی دیگه‌ قبلا اینكارهارو كردن ن؟رشون بدن واگر نمونه‌ی دارن بزرن كلیمات اینگلیس كه‌ من میخواهم ایستفاده‌ كن بیشتر 55000 هست ممنون

Felony

دوشنبه 16 آبان 1390, 19:36 عصر

بهترین گزینه برای این کار میتونه SQLite باشه .

akar_program

دوشنبه 16 آبان 1390, 19:48 عصر

بهترین گزینه برای این کار میتونه SQLite باشه .

ممنون اجوابتون پس اكسس مشكیلش چی هست من دوست دارم اكسس ایستفاده‌ كنم چون من با اون كار كردم میخواهم همون كار كانم
ئا یا اكسس بكار ببرم چه‌ مشكیلاتی پیش میاد ؟؟

Felony

دوشنبه 16 آبان 1390, 20:29 عصر

هیچ مشکلی پیش نمیاد ؛
- فقط حجم فایل های بانک تولید شده به وسیله SQLite کم حجم تر از اکسس هست .
- نیازی به نصب بودن Engine خاصی برای اجرا نداره ( البته Engine مورد نیاز برای کار با اکسس 2003 به قبل توسط ویندوز به صورت خودکار نصب میشه ) .
- SQLite یکسری مزیت های دیگه مثل Cross Platform بودن داره که اگر بعدا بخواین برنامتون رو برای یک Platform دیگه کامپایل کنید و توسعه بدید از شر به روز رسانی پایگاه خلاصتون میکنه و همون فایل بانک قبلی روی پلتفرم جدید قابل استفاده هست ، البته فکر نمیکنم این مزیت ها به کار شما بیاد .

:چشمک: شما از همون Access استفاده کن .

akar_program

دوشنبه 16 آبان 1390, 20:39 عصر

هیچ مشکلی پیش نمیاد ؛
- فقط حجم فایل های بانک تولید شده به وسیله SQLite کم حجم تر از اکسس هست .
- نیازی به نصب بودن Engine خاصی برای اجرا نداره ( البته Engine مورد نیاز برای کار با اکسس 2003 به قبل توسط ویندوز به صورت خودکار نصب میشه ) .
- SQLite یکسری مزیت های دیگه مثل Cross Platform بودن داره که اگر بعدا بخواین برنامتون رو برای یک Platform دیگه کامپایل کنید و توسعه بدید از شر به روز رسانی پایگاه خلاصتون میکنه و همون فایل بانک قبلی روی پلتفرم جدید قابل استفاده هست ، البته فکر نمیکنم این مزیت ها به کار شما بیاد .

:چشمک: شما از همون Access استفاده کن .

ممنون همون اكسس ایستفاده‌ میكنم ولی تا حالا موندم از چه‌روشی اطلاعات دیكشنریمون بنویسم با همون روشی شوما بنویسم یا همون روشی yousjoon یا همون روشی خودم یا یك روشی دیگه‌

سعید صابری

دوشنبه 16 آبان 1390, 20:45 عصر

البته قبل از شروع کمی درباره Hash table تحقیق کن شاید بدردت خورد

Felony

دوشنبه 16 آبان 1390, 20:52 عصر

من وقتی داشتم اون پست رو میدادم حواسم به این نبود که ممکنه ترجمه های بلعکس دارای چند جواب باشن ، در این صورت طراحی yousjoon نرمال سازیش بهتر هست چون از یک Junction Table برای ارتباط بین جدول ها استفاده شده و برای نوشتن Query ها کمتر به دردسر میافتید .

akar_program

دوشنبه 16 آبان 1390, 22:54 عصر

البته قبل از شروع کمی درباره Hash table تحقیق کن شاید بدردت خورد

سلام میشه‌ بگید چه‌ استفاده‌ی دارد برای كار من ممنون

Felony

دوشنبه 16 آبان 1390, 23:29 عصر

سلام میشه‌ بگید چه‌ استفاده‌ی دارد برای كار من ممنون

برای شما هیچی ، همون Junction Table برای شما کافی هست .

سعید صابری

دوشنبه 16 آبان 1390, 23:53 عصر

سلام میشه‌ بگید چه‌ استفاده‌ی دارد برای كار من ممنون

برای شما هیچی ، همون Junction Table برای شما کافی هست .

چرا نداره جناب تاجیک؟

در واقع روش مناسبی نیست؟ یا دلیل دیگه؟

Felony

سه شنبه 17 آبان 1390, 06:25 صبح

چرا نداره جناب تاجیک؟

در واقع روش مناسبی نیست؟ یا دلیل دیگه؟
55000 کلمه که هر کدومشون فوقش 20 کاراکتر دارند چیزی نیست که بخوایم نگران سرعت و بازدهی Query هاش باشیم و همون Junction Table به خوبی از پسش بر میاد .

akar_program

سه شنبه 17 آبان 1390, 07:39 صبح

55000 کلمه که هر کدومشون فوقش 20 کاراکتر دارند چیزی نیست که بخوایم نگران سرعت و بازدهی Query هاش باشیم و همون Junction Table به خوبی از پسش بر میاد .

سلام اقای مجتبی تاجیک در مورد كاراكتر شاید كاراكتر هامون حودود 150 كاراكتر هست باز هم نیاز با Hash table ندارد ؟؟

akar_program

سه شنبه 17 آبان 1390, 07:45 صبح

سلام.
البته روش جناب تاجیک هم برای کارهای کوچک بسیار کاراست اما در طراحی مشکل ارتباط چند به چند داره.
برای مثال اگر یک کلمه رو به فارسی بنویسید و دنبال تمام معادل های کردی اون باشید..
یا اگر یک کلمه انگلیسی دارای دو معنی باشه اونوقت کلمه redundant می شه.
درست ترش اینه که جداول به این شکل باشند:

جدول کلمات انگلیسی
---------------------------------
ID EnWord

جدول کلمات فارسی
--------------------------------
ID FaWord

جدول کلمات کردی
--------------------------------
ID KuWord

جدول ارتباطات
--------------------------------
ID EnID FaID KuID

که در این جدول آخری مثلا اطلاعات به این شکل می شه: (ID در حقیقت سریال جدول هست و نمی نویسمش)

EnID FaID KuID
------------------
1 0 1
1 0 2
2 0 1
2 0 5
1 1 0
0 1 2
0 1 1
0 5 6

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

در خصوص اون قابلیت تایپ: در رویداد فشرده شدن کلید شما باید هر بار یک کوئری رو فراخوانی کنید که لایک مورد نظر رو فیلتر می کنه و اولیش رو میاره.
در مورد کامپوننت هم برای انگلیسی خود ویندوز این کار رو می تونه براتون انجام بده اما جایی دیده بودم که تلفظ های کلماتی رو که در دیتابیس وجود دارند رو هم در دیتابیس وارد کرده بودند..

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

جدول ارتباطات
--------------------------------
ID EnID FaID KuID

که در این جدول آخری مثلا اطلاعات به این شکل می شه: (ID در حقیقت سریال جدول هست و نمی نویسمش)

EnID FaID KuID
------------------
1 0 1
1 0 2
2 0 1
2 0 5
1 1 0
0 1 2
0 1 1
0 5 6

من دیتا بیس با این شكل دروست كردم لطف ببینن با این شكل دروست هست اگر زحت بكیشن یك نمونه‌ با دیتا بیسم پیوه‌ست كنن منون

یوسف زالی

سه شنبه 17 آبان 1390, 08:42 صبح

سلام دوباره.
بله ساختار درست هست.
اگر فرصت کنم یک نمونه براتون می گذارم.

Felony

سه شنبه 17 آبان 1390, 09:01 صبح

سلام اقای مجتبی تاجیک در مورد كاراكتر شاید كاراكتر هامون حودود 150 كاراكتر هست باز هم نیاز با Hash table ندارد ؟؟
خیر ، نیازی نیست .

akar_program

سه شنبه 17 آبان 1390, 09:16 صبح

سلام دوباره.
بله ساختار درست هست.
اگر فرصت کنم یک نمونه براتون می گذارم.

خیلی ممنون منتظر هستم ولی با اونو دیقت كنید شاید كاراكتر هامون برخی از كلیمه‌هامون بشه‌ 150 كاراكتر

یوسف زالی

چهارشنبه 18 آبان 1390, 22:39 عصر

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

akar_program

چهارشنبه 18 آبان 1390, 23:55 عصر

خیلی ممنون ولی من از اون fek سر در نیا وردم یانی باید من برای هر كلیمه‌ انها هم مشه‌ خس كنم
وهم این روش فقط بر اساسی اینگلیزی هست من میخوا سا ده‌ تر باشد من توی دیتا بیسم كلمه‌ های تكراری نیست اگر بیام از لیك ایستفاده‌ كنم باز هم اشتبا هست مسلن با این شكل
سه‌ تا چیك باكس دروست كنم بنویسم en - fa - ku با دیك زدنش بر اساس او ن در دیتا بیس سرچ كنم در یك جا كلیمه‌های مقابلش نیشون بده‌م
مسلن مینویسم buy بر اساس اینگلیزی سرچ كند مسلن میاد buy در id 60 دیتا بیس اینگلیسی پیدا میكند بیاد id 60 دیتا بیس فارسی و هم كوردی در مقا بلش نیشون بده‌ ایا این را ه مشكیلش چی هست