Pourquoi la plupart des gens disent que les services de données et la base de données sont les parties les plus importantes d'un système?
D'après ce que j'ai vu, c'est le développement de l'avant: GUI, Webui, XAML qui est le plus important. Certainement plus important que les niveaux moyens et de base de données.
Je ne pense pas que ce soit une grosse affaire de créer une base de données d'une application. Après tout, le schéma de données provient de l'analyse de l'entreprise et il y a très peu de travail «créatif» de la part du développeur de base de données. Il en va de même pour le côté logique de l'entreprise (niveau moyen). De plus, J2EE et le Cadre Enterprise .NET AFFICHENT pour rendre la logique commerciale simple à développer.
Alors, quel est le développeur de base de données qui est si important? Pourquoi avons-nous même besoin d'un développeur de base de données autonome? Pourquoi la plupart des entreprises paient toujours un salaire plus élevé aux développeurs moyens / backend au lieu de développeurs frontaux?
Je crois que les développeurs construisant l'interface utilisateur (en Java ou C #) devraient avoir des connaissances de base de données. Cela leur permettrait de construire l'ensemble de l'application. À mon avis, il est impossible de laisser une personne de connaissances à la base de données développer l'application de toute façon.
S'il vous plaît laissez-moi savoir ce que vous manquez ici.
Merci beaucoup.
10 Réponses :
Je crois que l'extrémité avant: GUI, Webui, XAML est plus important que niveau de niveau moyen et de base de données.
C'est un peu comme dit que la couleur d'une voiture est plus importante que le moteur et les pneus.
Ce n'est probablement pas un gros problème de construire une base de données. C'est cependant une grosse affaire pour la construction correctement, optimiser une optimisation d'un magasin de données bien conçu. IMO, c'est pourquoi la base de données / datastore les gars obtiennent les gros dollars.
Mais, à l'exception des geeks de voiture (et éventuellement des geeks généralistes, moi-même, et je ne sais rien des voitures) Un bon morceau du monde regarde la couleur de la voiture et ces choses triviales / cosmétiques peuvent faire ou casser une transaction.
Dans mon expérience, ces choses ne font que fabriquer ou casser des offres si tous les autres facteurs majeurs sont comptabilisés. Vous n'obtiendrez pas une nouvelle voiture verte sur un nouveau rouge si les deux étaient des moteurs manquants, n'est-ce pas?
Yugos n'a pas vendu parce qu'ils étaient laids et peu fiable. Combien de personnes vont acheter une jolie voiture si les pneus explosent au-dessus de 20 mi / h? "J'aime mon elise Lotus Elise, mais l'équipe de piste de lycée continue de me battre Evreywhere. Whassup wit dat?"
Parmi d'autres raisons: avec un niveau moyen solide, vous pouvez passer d'une interface graphique à une autre en fonction des exigences. (Dites de la conception de la pré-Web2.0 à Web2.0), donc beaucoup plus de planification est nécessaire pour le milieu et le backend niveaux comparés à un frontend éventuellement échangeable.
Tout est important.
Il est impossible de laisser une personne de connaissances de base de données à développer toute application.
pas si vous masquez les tables de base de données avec des procédures stockées enveloppées dans des services Web.
L'avant est simplement une peau sur la demande réelle.
Le niveau d'affaires moyen est le plus difficile à programmer l'OMHO, car les hommes d'affaires savent rarement quelles sont leurs exigences, malgré leur pensée. Ils changent régulièrement d'esprit. Les cas de bord épuisent un design agréable et peuvent être très difficiles à mettre en œuvre.
Peu importe la qualité de votre développeur de votre GUI s'il écrit une extrémité frontale sur un niveau d'entreprise mal écrit. Et vous ne pouvez pas écrire un bon niveau d'entreprise sur une base de données mal conçue.
En fin de compte, il est beaucoup plus simple de réécrire une interface graphique que de modifier le calque de base de données ou le niveau moyen, comme une modification de l'un ou l'autre de ceux qui affectent tous les niveaux ultérieurs du programme.
Pas si vous masquez les tables de base de données avec des procédures stockées enveloppées dans les services Web Yuck! Je suis tout pour la SOA, le cas échéant, mais tout ce qui vous convient avec Web Services + Les Procs stockés deviennent un design très procédural.
L'extrémité avant est généralement beaucoup plus facile à modifier, tandis que le backend a besoin de plus d'exigences et de phases de conception. S'il y a une modification du backend, le front-end devra probablement changer, de sorte que les demandes de modification des services de backend (DB, etc.) entraînent souvent beaucoup de changements à travers les extrémités du milieu et de l'avant. Un changement d'avant n'affecte généralement pas le backend.
La question DBA dépend vraiment de la taille de votre projet. Si vous parlez de projets avec quelques tables simples et quelques milliers de documents, vous avez probablement raison. Un vrai DBA considérera probablement que sous sa valeur de ce projet de toute façon. Un vrai DBA ressemble plus à un administrateur de systèmes spécialisé dans les optimisations de la SGBD. Presque tout programmeur peut construire des tables, des relations, des vues, des Procs stockés, etc. et surtout avec des ormes faciles à utiliser, beaucoup de choses que les dabas utilisés à faire ne sont pas vraiment nécessaires. Cependant, un DBA est crucial lorsque vous travaillez sur de grands projets et de grands systèmes de base de données pour les optimisations de la SGBD, la configuration du système, la configuration de basculement, etc.
Votre question originale ne parle pas de la portée du projet et je pense que c'est là que vous êtes confus ou que vous ne voyez pas l'importance d'un vrai DBA (à ne pas être confondu avec une personne qui connaît un peu de SQL ou des données entrée et s'appeler un DBA).
Pour une petite application que vous jetez ensemble, la base de données ne semble pas si importante, mais laissez cette application grandir et évoluer au fil du temps et que vous rencontrez rapidement des pièges en raison d'une mauvaise conception.
La couche de base de données et le niveau moyen sont les clés de la longévité et de la maintenabilité de votre application.
La logique des entreprises est toujours simple avec l'aide J2EE ou DotNet Enterprise Framework.
Bien sûr, le codage de la logique commerciale a tendance à être simple ... Si vous n'avez pas à vous soucier des exceptions, une manipulation des erreurs, d'obtenir les bonnes exigences de l'entreprise, etc. Ajouter dans la capacité (nécessaire maintenant plus que jamais) pour une seule application pour prendre en charge plusieurs fronts (Web, bureau, mobile) et tout à coup, la logique commerciale «simple» devient un point critique.
Certains du travail le plus difficile que j'ai fait en tant que programmeur traite des interfaces utilisateur (XHTML, XAML, Servlets, MVC, ASP.NET, etc.). Cela étant dit, je pense que vous rencontrez deux problèmes différents. De la base de données, comme l'a dit Mathew, un véritable DBA va pouvoir optimiser une base de données importante (des millions de documents) d'une manière un développeur ordinaire ne saura pas comment. Sur le niveau moyen, je pense que la raison pour laquelle l'interface utilisateur est souvent tellement complexe est que le développeur ne construit pas vraiment un véritable niveau de logique moyen / économique. Donc, ils finissent par mettre toute la logique dans l'application dans l'interface utilisateur, ce qui ne va pas. Trouver de bons développeurs qui savent construire une couche d'entreprise solide et orientée objet qui connaît des motifs de conception et de conception oo du domaine est rare. Construisez un tas de classes avec uniquement getters / Setters correspondant à vos objets de base de données, ce n'est pas une conception orientée objet. Par conséquent, ils valent la peine de plus.
Autre que cela, je conviens que le travail de l'interface utilisateur est une programmation très difficile et devrait être considéré comme plus important qu'aujourd'hui.
+1 - Bon commentaire - J'aimerais pouvoir uppouver deux fois.
Cependant je ne vois pas de bonne conception de niveau moyen même au soleil
Il est impossible de répondre à votre non-question.
Il est basé sur une prémisse que tout le monde pense que la base de données est la chose la plus importante dans tous les systèmes - qui est fausse, évidemment - non seulement toutes les personnes ne pensent pas que, de nombreux systèmes n'utilisent pas de bases de données et de nombreuses personnes expérimentées seront d'accord que les parties les plus importantes de différents systèmes varient d'un système au système.
En fait, par la définition d'un système, chaque partie doit être importante! Il est possible que certains sous-systèmes puissent être plus chers que d'autres, d'autres plus tolérants de fautes que d'autres, des autres remplaçables de manière modulaire et d'autres non, mais tous font partie d'un système et sont donc importants. L'idée que l'on est plus important est difficile à quantifier. Il est concevable que certaines parties soient facultatives (comme une décoration de «non-séduisante»), et peut donc ne pas être considérée comme faisant partie du système. Cependant, dans la vue plus large du système, les utilisateurs participent et leur interaction efficace et joyeuse avec le système est essentielle pour assurer son succès.
Pour utiliser une analogie déjà affichée ici, la peinture sur une voiture pourrait ne pas être aussi importante que le moteur, mais que quelqu'un vendrait-il une voiture non peinte? - Peu probable (sauf si c'était la définition du produit - comme des meubles inachevés).
De la même manière qu'un moteur coûte plus cher qu'un travail de peinture, je m'attendrais à ce que nous payions plus aux personnes de concevoir des moteurs que de sélectionner des couleurs de peinture.
Il y a un spectre de spécialités et de complexités dans tous les systèmes.
il ne signifie pas que tout le monde peut bien coder en VC ++, même s'ils ont une connaissance en C ++.
Dans le monde technique actuel, chaque développeur a eu des connaissances de base sur la plupart des technologies les plus récentes. Cela ne signifie pas qu'ils sont prêts à concevoir un système avec toutes les technologies.
C'est tout issu d'expérience et de votre spécialisation. N'oubliez pas qu'ils ont bien payé pour faire de DBA, ne pas faire de la conception de l'interface utilisateur.
Cela ne signifie pas que les développeurs d'interface utilisateur ne peuvent concevoir un dB. Vous pouvez également devenir un bon concepteur de DB, si vous avez suffisamment d'expérience avec la conception d'une base de données.
Où est-ce que C ++ est entré dans cette conversation? Il me semble que l'utilisation de C ++ dans une application commerciale est jolie archaïque.
Je ne dis pas qu'une base de données est la fin ou que vous soyez tous, mais s'il vous plaît, travaillez dans le monde réel avant de le remettre en question.
Ne comprenez pas le bowvote. Juste parce que la question est un peu à courte vue ne signifie pas que c'est une question invalide. +1.
Quelle est la question? Qui est le tout le monde qui dit que la base de données est le plus important? Quel type de systèmes? Pourquoi cette question est-elle importante?
Je ne suis pas d'accord avec les hypothèses de la question (que l'interface utilisateur est plus importante que les modèles de données / modèles de données sont faciles). Cependant, j'ai réparé la grammaire afin de ne pas être évité simplement parce que les gens trouvaient qu'il est difficile de comprendre. Espérons que les gens ne penseront pas que c'est ma question!
Beaucoup de bonnes réponses - upvotes tout autour!
Avez-vous déjà vu une base de données mal construite? Avez-vous déjà dû faire face à des problèmes de connectivité car les données ne sont pas disposées de manière à ce que les données soient bien échiées?
Je ne sais pas quelles couches sont plus "importantes", mais à mon avis, le front-end est certainement la partie la plus difficile à développer.
Il n'est pas facile de concevoir une base de données mal construite même pour un développeur de niveau d'entrée. Je suis entièrement d'accord avec Jacob