ما هي قاعدة بيانات المصدر المفتوحة هي الخيار الأفضل لنظام مرتبط بالمحاسبة؟ [مغلق

StackOverflow https://stackoverflow.com/questions/411976

سؤال

أنا في المراحل المبكرة من التخطيط وتصميم تطبيق محاسبة مخصص لشركتي. هدفي هو الاستفادة من قاعدة بيانات علائقية مفتوحة المصدر لجزء تخزين البيانات وأنا على دراية بقواعد بيانات صلبة مدعومة على نطاق واسع: MySQL و PostgreSQL.

بالنسبة للنظام الذي سيتطلب المعاملات ، والإجراءات المخزنة ، والوظائف ، والأمان ، هل هناك أي آراء حول أي من قواعد البيانات هذه سيكون أكثر ملاءمة لتطبيق محاسبة أم أن هناك قاعدة بيانات أخرى أفتقدها؟

أنا أكثر دراية بـ MySQL و MS SQLServer 2005 ، لكنني أحاول الابتعاد عن الأخير بسبب تكاليف الترخيص.

اسمحوا لي أن أضيف: هذه ليست حاجة محاسبية مثل QuickBooks أو Peachtree. هذا هو في الأساس نظام يتعامل مع المحاسبة لخدمة أعمال محددة نقدمها. ربما يكون هناك نظامان أو ثلاثة أنظمة تلبية هذه الحاجة ، ويتم تسعيرها في نطاق الرقم الستة قبل أي تخصيص ، وستتطلب من شركتي الصغيرة أن تتزوج من بائع على المدى الطويل. وبالتالي ، نحن نبني التطبيق في المنزل.

أيضا ، بينما أقدر شراء مقابل البناء الحجة ، أود الابتعاد عن هذا السؤال الديني بالذات لأن طريق الشراء تم أخذه بالفعل وفشل البائع فشلاً ذريعًا. في بعض الأحيان تحتاج فقط إلى القيام بالمهمة بنفسك وهذا المشروع والميزانية المحددة يستدعي ذلك.

شكرا على ردود الجميع حتى الآن.

هل كانت مفيدة؟

المحلول

هناك أربعة أنظمة رئيسية لإدارة قواعد البيانات العلائقية مفتوحة المصدر والتي قد تكون مناسبة لهذا النوع من التطبيق: postgreSQL ، MySQL ، Firebird و Ingres. هناك أنظمة أخرى مثل sqlite ، لكنهم ليس لديهم هذا النوع من الهندسة المعمارية وليست مصممين حقًا لهذا النوع من عبء العمل. توجد بعض أنظمة إدارة قواعد بيانات مفتوحة المصدر من هذا النوع ، ولكن لا يبدو أنها قابلة للحياة بقوة لسبب ما ، مثل عدم التزام البائع الظاهر. مثال على النظام الذي يحتوي على هذا النوع من المشكلات SAP-DB.

postgresql يحتوي على أفضل مجموعة ميزة من أي من قواعد بيانات المصدر المفتوح ، ودعم معاملات XA ، والتي ربما تريدها إذا كان تطبيقك هو نظام من ثلاثة مستويات ويدعم معاملات التعقيد غير التافهة. على وجه الخصوص ، ستحتاج إلى هذا إذا كنت تريد إجراء معاملات تمتد أكثر من مكالمة واحدة إلى قاعدة البيانات.

تم بناء العديد من المتغيرات التجارية من PostgreSQL على مر السنين ، مثل توضيح ، البرقوق الأخضر و EnterprisedB. كان Illustra إصدارًا تجاريًا لـ PostgreSQL والذي تم شراؤه لاحقًا بواسطة Informix. GreenPlum عبارة عن إصدار mofified مصمم لتطبيقات تخزين البيانات. ExpressionB هي شركة توفر إصدارات تجارية مدعومة من PostgresQL مع بعض البرامج ذات القيمة المضافة.

MySQL 5.x يحتوي على مجموعة ميزة تدعم مقطعًا عرضيًا معقولًا من القدرات ، ولكنه ليس غنيًا بالميزات مثل postgreSQL. إنه يتمتع بقبول كبير على نطاق واسع وسيكون أسهل أنظمة إدارة قاعدة البيانات مفتوحة المصدر لتوظيف مطوري ماهر. على الرغم من أن الإصدارات القديمة لم يكن لها دعم قوي للمعاملات ، إلا أن محركات تخزين المعاملات مثل innodb كانت متاحة لبعض الوقت. ال تيار سياسة المحيط ولدت عملية الاستحواذ من Sun الشوكات الرمز والمناظر الطبيعية MySQL فوضوي إلى حد ما ، مع الجدل قضايا الجودة في الإصدار 5.1. ومع ذلك ، فإن MySQL هو إلى حد بعيد أكثر أنظمة إدارة قاعدة البيانات المفتوحة والمصدر ، وهي الوحيدة التي تتمتع بتعرف كبير على العلامة التجارية خارج الدوائر مفتوحة المصدر.

فايربيرد هو نسخة مفتوحة المصدر من interbase. أخيرًا نظرت ، لم يكن لديه دعم XA ولكن سيكون جيدًا إذا تم إعداد تطبيقك كنظام خادم عميل من مستويين. تحديث: لا يمكنني العثور على مواصفات نهائية حول هذا الموضوع ، لكن الوثائق تشير إلى أن لديها دعمًا للالتزام على مرحلتين ، لكن ما يمكنني العثور عليه لم يكن محددًا فيما إذا كان يدعم بروتوكول XA. تشير الوثائق إلى أن برنامج تشغيل JDBC لديه دعم للالتزامات ثنائية الطور.

متغير مثير للاهتمام في هذا النظام Fyracle, ، وهو مصمم لتقديم درجة من التوافق مع Oracle. تم تطوير هذا في الأصل لاستخدامه كخلفية خلفية ل compiere, ، التي بنيت ضد أوراكل وتواصل معها بإحكام.

الينغو متوفر الآن برخصة مفتوحة المصدر ، ولكن تم استقبالها بقليل من التثاؤب الجماعي من قبل المجتمع مفتوح المصدر. ومع ذلك ، فهي غنية بالميزات وناضجة للغاية - أعرف أن الأشخاص الذين كانوا يقومون بتطبيقات Ingres في عام 1990 ، ويعود تاريخه إلى الثمانينات.

نصائح أخرى

نصيحتي؟ لا. من الأفضل شراء واحدة. لقد كتب الأشخاص الذين يعرفون المزيد عن المحاسبة حزمًا جيدة تتعامل بالفعل مع GAAP. لديهم قاعدة مستخدم أكبر مما لديك ، والتي ستكشف عن العيوب بشكل أسرع. هذا هو الكلاسيكية "شراء مقابل بناء". لا توجد ميزة تنافسية لشركتك من خلال كتابة خاصة بهم. إذا كنت تفعل ذلك لأنك قلق بشأن تكاليف الترخيص ، فأنا أقول إنك لم تمثل وقت التطوير بشكل صحيح. هذه هي الطريقة الوحيدة التي يمكنك بها تبرير القيام بذلك في المنزل.

مع ذلك ، إذا كنت قلقًا بشأن تكاليف ترخيص SQL Server ، فإنني أوصي بـ PostgresQL أولاً أو MySQL الثانية كقاعدة بياناتك المفضلة.

أوافق بشدة على إجابات من Duffymo و Tuinstoel وغيرها. أعد النظر في قرار بنيتك مقابل شراء القرار. اسمحوا لي ان اقول لكم قصة:

بينما كنت أعمل في شركة متوسطة الحجم (International ، أكثر من 100 مليون دولار/سنة) ، قرر المدير المالي استبدال الأنظمة المالية بـ Oracle Financials. فقط هذه الحزمة لا تتطابق تمامًا مع الممارسات المحاسبية التي تستخدمها هذه الشركة.

لذلك استأجر المدير المالي فريقًا من مبرمجي العقود ، ودفعهم لتخصيص Oracle Financials للممارسات المحاسبية المفضلة. غرقت 12 شهرًا من الوقت ، وأجور المبرمج بقيمة مليون دولار ، بالإضافة إلى التكلفة الأولية للبرنامج ، فقط لتكرار نظام المحاسبة الذي كان يعتزم استبداله.

قالت إذا كان عليها أن تفعل ذلك مرة أخرى ، فستشتري الحزمة التجارية ، ولكنها تكيف العادات المحاسبية للشركة مع الافتراضات التي يدعمها البرنامج. سيكون ذلك أسهل بكثير وأسرع وأكثر عرضة للنجاح.

لذا ضع في اعتبارك تكلفة بناء الحزمة المخصصة الخاصة بك. ضع في اعتبارك أيضًا التكلفة المستمرة لشركتك من Maintanance ، وتصحيح الأخطاء ، والتحسين لهذا البرنامج. حتى إذا اشتري حزمة تجارية من ستة أرقام ، فمن المحتمل أن يكون ذلك أقل تكلفة من دفع المبرمجين لتطوير مثل هذا النظام والحفاظ عليه.


للإجابة على سؤالك المعلن بشكل مباشر ، لا أعتقد أن هناك فرقًا كبيرًا بين PostgreSQL و MySQL ذي الصلة بمشروعك. نظرًا لأنك مرتاح مع MySQL ، فقد تذهب أيضًا مع ذلك.

أود أن أقدم تذكيرًا إلزاميًا بعدم استخدام أنواع البيانات غير الدقيقة مثل FLOAT أو DOUBLE PRECISION للبيانات المالية.

إلى عن على أي التطبيق الذي يريد استخدام قاعدة بيانات مفتوحة المصدر ، الإجابة اليدوية هي postgres. إنه "جاهز للمؤسسات" أكثر بكثير من MySQL ، ناهيك عن أنه يتبع معيار SQL أفضل بكثير. لقد تحسنت MySQL كثيرًا مع إصداراتها اللاحقة ، لكن Postgres لا يزال يتفوق عليه في كل فئة.

هناك أنظمة محاسبة مجانية مفتوحة المصدر. مثل Osfinancials. لا أستطيع حقًا أن أفهم لماذا تريد بناء نظامك الخاص؟

لتطبيقك ، لن يكون الأمر مهمًا حقًا. من المحتمل أن يعمل أي شيء من SQLite إلى MySQL إلى Postgres على ما يرام. اختر الشخص الأكثر دراية به.

إذا كنت على دراية بـ MySQL ، فاستخدمه. لكن حدد محرك قاعدة البيانات السليم بدلاً من Myisam الافتراضي

قائمة محركات التخزين

بكل صراحه، أي من المشتبه بهم المعتادين سوف يقومون بهذه المهمة. الحفاظ على مخطط الحسابات وجداول البيانات ذات الصلة هو مشكلة الجذر التي دفعت معظم النموذج العلائقي. في الواقع ، إذا كنت تفكر في عرض المجلة العامة لنظام المحاسبة ، كل ما عليك لديك هو مخطط الحسابات والمجلة العامة ، المؤلفة من رقم المعاملة والتاريخ والوصف وحساب الخصم والمبلغ وحساب الائتمان والمبلغ. كل شيء آخر تفعله هو اختيار على هؤلاء.

ومع ذلك ، هناك الكثير من الحزم المالية الكافية والمختبرة جيدًا والمقبولة ، بما في ذلك إصدارات خالية من المصدر (كما هو الحال في البيرة) ، مما لم تقصد ذلك من أجل مشروع دراسة ، سأضع بلدي الجهد في Googling واختيار واحد.

شاهد التحديث الخاص بك. الشيء هو أن هذه مشكلة سيتم تحديدها في الغالب من خلال المتطلبات غير الوظيفية. هل ستقوم بتوزيع قاعدة البيانات عبر أكثر من خادم واحد؟ ما مقدار الحمل الذي تتوقعه؟ المعاملات في الثانية أو المعاملات في اليوم؟ لقد قمت ببناء أنظمة حول كل من العامين الماضيين ، وعادة ما تكون متطلبات الموثوقية والقابلية الأكثر حسمًا: يتعامل PostgreSQL مع التحديثات المتزامنة لصف واحد بشكل أكثر فعالية ، من خلال تطبيق atomicity الصف وتسلسل التحديثات المتزامنة. من ناحية أخرى ، يبدو أن MySQL يتعامل مع قواعد بيانات كبيرة حقًا. ومع ذلك ، فإن السؤال الثالث هو النسخ الاحتياطي --- واحد منهم (لا أتذكر أي واحد الآن) يتطلب أكثر أو أقل بعض الوقت للنسخ الاحتياطي.

لتطبيق محاسبة على شبكة الإنترنت في المنزل ، قد تكون أفضل حالًا مع Gemstone كقاعدة بيانات كائن مجانية ولكن غير مفتوحة المصدر والشاطئ البحري كإطار الويب. على خلاف ذلك المعروف باسم الزجاج.

للحصول على طلب داخلي ، ستكون محدودًا في جهود المطورين. توفر Gemstone ، كصورة صغيرة ، أفضل إنتاجية للمطور إلى حد بعيد. دعمها لترحيل الكائنات عند تغيير تعريفها يتيح تطوير تكراري حقيقي. يحل Seaside محل القوالب من خلال لغة خاصة بالمجال المصممة جيدًا لبناء تطبيقات الويب.

انا ابني برامج المحاسبة على postgresql. أنه يعمل بشكل جيد جدا. سأكون في غاية يوصي ذلك. في الواقع (قابس وقح) ، قد تفكر في العمل معنا لتحسين مشروعنا واستخدامه كنقطة انطلاق.

هناك بعض الأسباب على وجه الخصوص:

  1. يمنحك الاستماع/الإخطار القدرة على ربط البرامج الأخرى في DB المحاسبية عندما يتغير شيء ما دون الحاجة إلى التحقق من الجداول في كثير من الأحيان.
  2. لقد وجدنا أداءً جيدًا للغاية مع معظم الاستعلامات المعقدة.

سوف يمنحك Firebird و Ingres حل علائقي صخري شديد الصخور. MySQL لا أوصي لأنك تقوم حقًا بربط كل شيء بتطبيق واحد فقط يمكنه الكتابة إلى DB (تعني حساء وضع SQL أن العلاقات هي في الأساس واجهة برمجة تطبيقات خاصة بدلاً من واجهة برمجة التطبيقات العامة التي هم في postgresql و Firebird و Ingres) ، و هذا يعني أقل مرونة أسفل الطريق.

ومع ذلك ، مع PostgreSQL ، تحصل على منصة تطوير من الدرجة الأولى والقابلة للتمديد في صندوق. وتيرة التنمية عالية. إنه صخرة صلبة. الميزات المتقدمة مفيد جدا. لن تشعر بخيبة أمل. لم نكن.

إذا كان هذا تطبيق سطح المكتب ، فقد ترغب في إلقاء نظرة على SQLite. إنه معروف جيدًا ، في المجال العام ، وليس من الصعب للغاية العمل معه.

لأنك لا تفعل ذلك بحاجة إلى الإجراءات المخزنة ، خذ هذا من قائمتك.

ستكون أكثر سعادة وضع منطق العمل في التعليمات البرمجية ، وليس في قاعدة البيانات. إذا كانت لديك فرصة لبدء "نظيف" ، فاستخدم قاعدة البيانات لما هو أكثر منطقية - عدم الاستمرار في عدم المعالجة.

بمجرد اتخاذ هذا القرار ، تختفي الاختلافات الدقيقة بين MySQL و PostgreSQL. كلاهما محركات علائقية تتعامل مع SQL متطابقة تقريبًا. ركز على الأشياء التي يفعلونها بشكل أفضل.

توصية: اجعل تطبيقك مستقلًا عن أي خصائص قاعدة بيانات.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top