Alternativa per Access + SQL Server per progetti aziendali [chiusa]

Le applicazioni scritte con Access e in particolare Excel tendono a comparire nelle organizzazioni ogni volta che problemi aziendali specifici devono essere risolti rapidamente e in modo ad-hoc con supporto zero o minimo da parte degli sviluppatori professionisti. Questi sono strumenti BUONI e POTENTI e questo è un modo perfettamente valido per usarli.

I problemi iniziano quando requisiti e problemi diventano più complessi e i sistemi ad-hoc esistenti basati su Access o Excel non possono più tenere il passo perché nessuno li sta mantenendo o la scala sta diventando troppo grande da gestire.

Non penso che la tua organizzazione abbia questi problemi. Perché? Perché probabilmente ci sono persone dedicate allo sviluppo e alla manutenzione di questo prodotto che presumibilmente hanno un strong controllo dell'applicazione e del suo modo di scalare. Nelle mani giuste e nel giusto contesto, Access è perfettamente in grado.

Penso che il vero problema sia trovare persone per sviluppare / mantenere questa applicazione a lungo termine. L'accesso non è altrettanto attraente / glamour delle altre tecnologie. Questo da solo potrebbe essere sufficiente per prendere in considerazione almeno la migrazione ad altre piattaforme applicative.

L'accesso, l'applicazione, sarà disponibile per molto, molto tempo. Ha un valore e un posto nel mondo IT, ma Access NON è una soluzione di livello Enterprise. Periodo.

Devi creare un front-end in C # o VB.NET (presumendo che tu stia mantenendo lo stack MS). Hai un sacco di scelte, WinForms, WPF, ASP.NET, Silverlight. E quale sceglierai dipenderà davvero dalla tua attività, dalla tua applicazione e dalla direzione verso la quale desideri orientarti.

Se stai costruendo la tua azienda su questa applicazione, è giunto il momento per la società di maturare e diventare un front-end maturo.

L'accesso ti servirà come front end, anche per le applicazioni "Enterprise". Non sono sicuro di cosa intendi per "tecnologie influenti", ma è più probabile che sia semplicemente scioccato. Tonnellate di aziende davvero massicce usano Access e (shudder) Excel per guidare le funzionalità mission critical, non le ostacoleranno un po '. Diavolo, SharePoint è considerato molto più Enterprisey e selezionerei Access su quel grumo di * & $ (& $ # tutti i giorni.

Le tecnologie Web, desktop e di altro tipo dovrebbero essere impiegate quando soddisfano le esigenze di un'azienda, non danno alla soluzione una qualche nozione di merito. L'intero problema sembra una falsa pista.

Le aziende si preoccupano delle soluzioni che funzionano, sono utilizzabili, possono adattarsi alle loro esigenze e che la società dietro di loro è sensibile al cambiamento e può supportare il prodotto.

I linguaggi di programmazione generali come C # o Java tendono a essere scelti perché si presume che siano più flessibili, ma se hai già una soluzione in Access, mi suggerisce che Access è una soluzione eccellente.

Ecco alcune cose che prenderei in considerazione:

1. Il codice di accesso è mantenibile?
2. Usi il controllo del codice sorgente?
3. Come gestirai eventuali personalizzazioni di cui potrebbero aver bisogno?
4. Puoi assumere persone per mantenerlo?

Ci sono soluzioni C # / Java buone e cattive, e ci sono anche soluzioni di Access buone e cattive. Personalmente, penso che le app CRUD / reporting che scriviamo con WPF / WinForms / Silverlight dovrebbero essere costruite con Access.

Se sei sicuro che la tua soluzione di Access soddisferà le esigenze dei tuoi clienti, non lasciare che i pregiudizi tecnici ti spingano a ricostruire qualcosa che funzioni.

Quello che potresti voler considerare è come cambierà il tuo prodotto per soddisfare le esigenze aziendali. Invece di forme e dati, ti piacerebbe creare interfacce utente più intuitive e basate su attività? Se ci sono funzionalità che vorresti aggiungere che sarebbero difficili o impossibili da fare in Access, allora questo potrebbe giustificare un cambiamento.

(Dico questo come programmatore WPF / ASP.NET di giorno)

L'accesso può essere un ottimo strumento per le applicazioni inter-office e le applicazioni di produzione su piccola scala, ma il problema è che non è scalabile a livello aziendale.

Hai menzionato che la tua azienda sta crescendo e con questa crescita hai bisogno di un front-end migliore che rappresenti l'avanguardia della tecnologia e infonda fiducia nei tuoi clienti sulle competenze tecniche fornite dalla tua azienda.

Alcune opzioni:

1) Se si sta considerando un'applicazione desktop su due livelli, consultare .NET Entity Framework come framework di persistenza per l'accesso ai dati con SQLServer. Le tue visualizzazioni possono essere progettate usando WPF. È una delle migliori combinazioni che ho visto per le applicazioni desktop a due livelli.

2) Basato sul web, se stai considerando l'approccio basato sul web e non sei troppo appassionato di tecnologie .NET, allora guarda il framework J2EE e JSF con Hibernate come framework di persistenza per SQLServer. Ci sono numerosi libararies di componenti disponibili per creare applicazioni web ricche con codice minimalista pulito.

Microsoft Access non supporta più l'interazione diretta con SQL Server (Access Data Projects) è stato rimosso da Access 2013 - l'unica opzione è quella di passare attraverso una licenza di connettore esterno Enterprise SharePoint che è letteralmente $ 60 grande.

OpenOffice / LibreOffice ha alcune grandi abilità per connettersi direttamente a mySQL. Non li uso da un paio d'anni, ma esco su un arto e dico che sono più facili da usare rispetto alle tabelle Access / Jet / Linked. Client-Server è un algoritmo più efficiente, è sempre stato .. e lo sarà sempre.

Inoltre, Microsoft "Visual Studio Lightswitch" è un'ottima alternativa ad Access. Permette una semplice immissione dei dati basata sul web. Non ho mai integrato Reporting Services con lightswitch, ma sembra un sogno diventato realtà.

Se non è rotto, non aggiustarlo. Ho usato questa frase due volte oggi, e non sono sicuro che sia abbastanza professionale, ma la realtà dimostra che è corretta di volta in volta ...

È bene anticipare i cambiamenti ed essere pronti per questo, ma prima devi definire chiaramente il tuo problema , ad esempio:

• Prevedete un grande volume di dati?

• Esiste una mancanza di esperienza nell'attuale applicazione?

• Principali modifiche nella logica?

• Prevedete più utenti?

• Necessità di elaborazione distribuita?

• Necessità di accesso web?

• Necessità di supportare dispositivi speciali?

• Devi avere un'applicazione più sicura?

• E così via ...

Senza rispondere a queste domande, non sarai in grado di scegliere la soluzione giusta per il problema.

Fatto: qualsiasi tecnologia scelta oggi sarà la storia tra qualche anno. Ad esempio, WPF non è così elegante come si prometteva di essere perché Silverlight è il nuovo bambino in città e anche questo è stato sfidato da HTML5 + JavaScript e la storia potrebbe continuare all'infinito.

Assicurati di aggiungere all'elenco di cui sopra, il momento in cui prevedi che la modifica è necessaria e la capacità del tuo personale o della tua organizzazione di investire nell'intelletto umano necessario per la migrazione.

Immagino che tu sappia che la tua organizzazione non è particolarmente matura e che vuoi migliorare le cose e diventare più professionale. Quindi, vorrai assicurarti di avere bug tracking, controllo della versione, controllo della release ecc.

Dato ciò che hai & quello che sai suggerirei di abbandonare Access e passare a Winforms .NET usando VB come linguaggio di programmazione perché sarà vicino a quello che hai al momento ma sarà molto più facile da supportare - Non credo che Access si integri bene ad esempio con il controllo della versione. Rimanere con SQL Server, è un buon prodotto. Considera di passare a C # anziché a VB perché C # è una lingua e un linguaggio migliore Microsoft sta sviluppando C # in modo più attivo. Sarà più difficile fare quel salto, quindi potresti voler iniziare con VB.