IDS un over-kill pour une application mono-utilisateur?

Question

J'ai le dilema suivant: Mes clients (les prêteurs sur gages de maman-n-pop) ont employé mon mgmt. système, développé avec ISQL, depuis plus de 20 ans. Tout au long de ces deux décennies, j'ai adapté l'application au désir de chaque client, ou lorsque des changements dans les lois/règlements l'ont exigé. La plupart des clients sont des sites mono-utilisateur. Certains ont plusieurs magasins, mais n'ont jamais voulu une base de données distribuée, ne font pas confiance à la fiabilité ou la sécurité de l'Internet ou tout autre type de réseau. Donc, ils utilisent tous des moteurs standard. J'ai pu contourner certaines limitations SE et faire quelques astuces avec ISQL et SE, mais tôt ou tard, de nouvelles lois pourraient exiger des images de clients prêteurs sur gages, de marchandises, de transmissions électroniques, etc. à IDS, réécrivez l'application dans 4GL ou passez à un autre SGBDR. L'itinéraire logique et le plus facile serait IDS/4GL, cependant, quand j'ai mentionné Linux ou des plateformes Unix-like à mes clients, ils ont réagi négativement et ont demandé une plate-forme Windows, donc la solution la plus simple pourrait être 4Js, Querix, etc. ou Access, Visual FoxPro ou ??? .. quelqu'un a des suggestions?

Answer 1

Regardez Aubit4GL - c'est, je crois, disponible (ou peut être compilé sur) Windows.

Oui, IDS se rapproche de l'overkill pour un système mono-utilisateur, mais si SE ne fournit pas toutes les fonctionnalités dont vous avez besoin, ou si vous anticipez avoir besoin dans un proche avenir, c'est un choix parfaitement judicieux. Cependant, avec un minimum de soin, il peut être configuré pour être (essentiellement) complètement invisible pour l'utilisateur.Et pour une application non stressante comme celle-ci, la configuration n'est pas compliquée. Vous, en tant que fournisseur, devez être assez avertis à ce sujet. Mais il existe des fonctionnalités telles que l'installation silencieuse, de sorte que vous pouvez demander à votre propre installateur d'exécuter le programme d'installation IDS pour obtenir le logiciel sur la machine du client sans plus attendre. La taille totale du système augmenterait - IDS est beaucoup plus grand sur disque que SE (mais vous obtenez beaucoup plus de fonctionnalités). Il existe également des mécanismes pour éliminer les plus gros morceaux de code que vous n'utiliserez pas - selon toute probabilité. Par exemple, vous utiliseriez probablement ON-Tape pour les sauvegardes; vous omettez donc ON-Bar et ISM de ce que vous expédiez aux clients.

IDS est utilisé dans les systèmes embarqués où il n'y a pas d'utilisateurs ni de gestionnaires travaillant avec le système. Le matériel se trouve dans le placard (placard) et fonctionne, communiquant sur le réseau.

Answer 2

Tout ce problème se résume à quelques problèmes que vous aurez à traiter.

La première chose est ce que la programmation de l'application et le langage de développement Êtes-vous prêt à apprendre et à travailler avec?

L'autre chose est ce genre de capacités Internet que vous voulez? Par exemple, lorsque vous consultez un rapport, souhaitez-vous pouvoir cliquer sur un bouton pour convertir le rapport en document PDF, puis lancer le client de messagerie avec ce document PDF joint? Qu'en est-il après avoir entré toutes les données d'information dans le système, peut-être que chaque magasin aimerait leur propre site Web miniature dans lequel les gens de la ville pouvaient se rendre là-bas pour vérifier ce qu'ils avaient à téléphoner au magasin. et demandez-leur s'ils ont un briquet d'occasion 3 $ (le travail du téléphone et la vérification de ces articles bon marché est PLUS que le coût de la vente de l'article - donc web vraiment super pour ce type de scénario).

L'autre question est quel type d'interface voulez-vous? Je suppose que vous avez actuellement un type d'écran vert ou une interface basée sur le texte? Ou peut-être au fil des années vous avez converti sur une interface graphique (interface utilisateur graphique).

Si l'écran est toujours vert (basé sur le texte), vous devez maintenant vous asseoir et donner beaucoup de temps et d'efforts dans la mise en page et la façon dont les écrans fonctionneront avec un système graphique. Je me souviens qu'en allant des écrans verts à la couleur, tout à coup les choix et les efforts pour choisir les couleurs et les dispositions correctes pour cet écran ont augmenté la charge de travail de beaucoup. Et puis je suis passé des écrans de test de couleur à celui d'une interface graphique, puis tout à coup, nous avons maintenant un grand nombre de nouveaux contrôles, couleurs, et en plus de cela, nous avons un grand choix en termes de polices différentes et tailles. Puis, maintenant, avec le Web, non seulement vous faites face à différents types de styles de bouton (rond, ovale, ombrage, ombres, effets de lueur), mais en plus de tous ces effets de survol et effets d'ombrage, etc. Il faut se poser des questions assez sérieuses sur le type de couleurs (thème) que votre logiciel adoptera pour l'ensemble du site. Cela dépend de l'apprentissage et du temps que vous êtes prêt à investir dans de nouveaux outils et de la quantité de logiciels que vous pouvez et que vous allez produire pour un temps et des efforts donnés.

Je ne suis pas du tout à l'aise avec les outils RAD lorsque vous vous trouvez sur le marché des petites entreprises. La plupart des petites entreprises ne peuvent pas se permettre les tarifs pour un développeur .net (ce n'est pas tellement le taux, mais le temps de construire une application). Donc, en utilisant ms-access est un bon choix dans le marché des petites entreprises.L'accès est toujours un bon 3 à 5 fois beaucoup d'autres outils sur le marché. Donc citation par développeur .net pour développer quelque chose pourrait être de 12 000 dollars, et la même chose dans Access pourrait être de 3000 $. Je veux dire que les petites entreprises ne peuvent pas vous payer pour écrire un code de test unitaire. Ce type de coût supplémentaire ne va tout simplement pas arriver sur les projets à plus petite échelle.

L'autre grand problème que vous avez à traiter est quel type de système d'écriture de rapports allez-vous construire dans le système? C'est une autre raison pour laquelle j'aime les applications d'entreprise plus petites, c'est parce que l'auteur du rapport est vraiment fantastique. Les rapports d'accès ont un tas de capacités pour faire des connexions à partir de formulaires et de requêtes et passer des filtres et des paramètres dans ces rapports. De plus, les formulaires et les requêtes que vous utilisez déjà peuvent souvent communiquer avec des rapports avec des paramètres et transmettre des valeurs de manière à réduire encore une fois la charge de travail (coûts de développement).

Je pense que le problème numéro un que vous devrez aborder ici est cependant ce que vous allez faire pour votre stratégie basée sur le Web? Vous devez absolument en avoir un. Même si vous construisez la partie frontale dans l'accès, vous pouvez toujours utiliser une version gratuite de SQL Server pour la partie back-end. Il y a plusieurs raisons à cela, mais l'une des raisons est que cela facilite la connexion de plusieurs magasins sur Internet. Un autre avantage de mettre vos données dans un système basé sur un serveur est maintenant que vous pouvez configurer un certain type de serveur web pour tous les magasins à utiliser, et construire un petit système de personnalisation qui permet à chaque magasin d'avoir leur produits et listes en ligne (mais, ils utilisent VOTRE serveur Web, ou celui que vous payez 15 $ par mois pour héberger tous ces clients). Cette partie Web pourrait être un composant optionnel que peut-être tous les clients ne veulent peut-être pas nécessairement. Il fonctionnerait de toutes les données qu'ils doivent entrer dans le système de toute façon. Un grand avantage de l'adoption de ces systèmes basés sur le Web est non seulement de permettre à ces magasins de mieux servir leurs clients, mais aussi de vous permettre de convertir votre logiciel en un système basé sur les frais mensuels, ou à au moins une partie de celui-ci comme la partie d'hébergement Web optionnelle que vous offrez. Lorsque j'ai converti mes applications à long terme du logiciel de type mainframe à écran vert en applications bureautiques basées sur Windows, cela m'a ouvert de vastes marchés. Avec le bureau à distance, le téléchargement de logiciels et la publication de mises à jour depuis un site Web, ces nouveaux systèmes informatiques font de ces outils une solution très facile maintenant et surtout pour soutenir les clients dans différentes villes que vous n'avez jamais rencontrées. visage. Par conséquent, si vous parlez toujours principalement d'un seul utilisateur et d'un seul emplacement, Access réduira de beaucoup vos coûts de développement. Cela dépend vraiment de la complexité et de la richesse d'une application dont vous parlez. Si la taille et la portée du projet dépassent un développeur, vous parlez plus de la mise à l'échelle du développeur (contrôle du code source, méthodologie de développement d'objet, test unitaire, coût et temps de mise en place d'un système de base de données serveur comme serveur SQL etc.). Donc, ils sont certainement un point de basculement ici lorsque vous allez au-delà de ce point de basculement de temps de coût dans une ville complexe, alors je ne recommande pas l'accès. Donc, tout se résume au bon cheval pour le bon parcours.

Peut-être que la fin de la journée, il revient vraiment à quel système de développement d'applications êtes-vous prêt à investir le temps d'apprendre?

Answer 3

Il est bon de voir que les gens tirent encore profit des outils Informix «old school». Je n'ai jamais été adepte de Perform, mais le rédacteur du rapport ACE m'a toujours convenu. Nous avons sauté Perform et sommes allés directement pour FourGen, et je me plains que je n'ai jamais été aussi productif que j'étais avec FourGen. Il a eu son propre genre d'élégance de ses générateurs de code à cela génial, mais en fait quitter le système de menu autonome puissant. J'apprécie la dynamique de l'interface utilisateur moderne, mais, damn, est-il difficile d'écrire des applications aujourd'hui. Pas seulement des outils, mais simplement des exigences de l'industrie et al (comme vous pouvez éprouver dans votre domaine). Et le Web est juste un meurtre à plat. Je suppose que c'est en partie dû au fait que la plupart des applications "écran vert" se ressemblent, il est difficile d'en faire une qui semble mauvaise! Avec les interfaces graphiques et le Web, etc., vous ne pouvez pas vous contenter d'un bon ordre de travail et des étiquettes alignées.

Mais, hélas, tel qu'il est, c'est ce que nous avons. Je ne l'ai pas utilisé depuis maintenant 15 ans, mais vous pouvez aussi regarder Alpha 5. C'était un paquet de développement de base de données assez puissant, mais pas trop compliqué, et (apparemment) toujours très performant .

Je n'aurais pas trop peur de l'IDS. Cela fonctionne assez simplement. En dehors de la boîte avec zéro ou peu peaufiner, la DB fonctionne et est efficace, et il était assez simple à installer. Ce n'était pas un SE, en ce sens que l'accès de SE était lié à l'application (en utilisant une bibliothèque) par rapport à un serveur indépendant qui est IDS. Mais, sur le plan opérationnel, c'est vraiment simple - surtout pour une application comme celle dont vous parlez. Je comprends que cela pourrait être exagéré, mais même aujourd'hui, les besoins en ressources ne seront pas forcément insensés. Il y a beaucoup de fonctionnalités, bien sûr, et de flexibilité que vous n'utiliserez pas. Mais franchement, au-delà des bases de données de style DBase "flat file", à peu près toutes les bases de données SQL basées sur le serveur sont très puissantes et capables et potentiellement compliquées. Mais ils ne doivent pas être. Ils peuvent toujours être utilisés "simplement" et facilement (enfin, économisez pour Oracle - Oracle ne peut rien faire "simplement"). Pour ce qui est d'explorer d'autres solutions, ne soyez pas effrayé par les trucs "OOP", car la plupart des applications, tout en exploitant les librairies OOP, ne sont pas vraiment OOP elles-mêmes (elles peuvent l'être, elles ne sont typiquement qu'aren) t, ils n'ont tout simplement pas besoin d'être). Le plus gros problème avec de nombreux systèmes OOP, c'est qu'ils sont simplement structurés. Traiter des événements à un niveau trop bas. Bien que de nombreux programmes aient besoin d'accéder à ce niveau de contrôle, la plupart des applications, en particulier celles qui ressemblent à la vôtre, ne le sont pas. Ainsi, la flexibilité supplémentaire entrave simplement ou crée plus de plaque de chaudière. Cela dit, vous ne devriez pas avoir peur d'eux en soi, citant un manque d'expertise. Ils peuvent être ramassés assez rapidement. Mais j'utiliserais d'abord les outils les plus spécialisés (comme Alpha 5, ou Access, etc.) d'abord pour voir s'ils n'offrent pas ce que vous voulez.

Answer 4

En termes de Visual FoxPro, était et reste un outil hors pair (malgré les critiques des personnes qui en savent peu à ce sujet). Il dispose d'un moteur de base de données natif rapide, d'un SQL intégré et d'un puissant concepteur de rapports, etc. Mais il faut aussi considérer que le support de Microsoft sera abandonné en 2014, il n'y aura jamais de version 64 bits, et ainsi de suite. Et la méthode de verrouillage de fichier qu'il utilise sera de plus en plus flou sur les futures versions de Windows IMO.