What conflicts arise between database developers and other departments?

One of the fundamental challenges for non-database groups (I will call them "coders") is the data gravity and state management in general. For compute-only stateless app developers is quite difficult to grasp the whole notion that one cannot just instantly switch from one version of a database to another version, or restore a petabyte of data post corruption, or move from one location to another by switching a branch of code. Data has gravity and defies many principles non-data folks follow. E.g. it is very difficult to optimize performance of dev code without full production copy of your data. Data people are heavily reliant on database vendors, and while there are claims of open-source databases, the real world uses proprietary solutions.

In my experience, Database developers and other departments often have trouble getting along because they look at things differently. Database developers are mainly concerned with keeping data safe and sticking to technical / database standards, but others might want systems that are easy and fast. This leads to misunderstandings because they don't always speak the same language. Additionally other departments may resist changes that database developers make to their systems, not fully understanding the reasons behind them. These departments often need data quickly, but database developers have to be careful and take their time to do things correctly, which can lead to frustration.

Testing and Quality Assurance: Database developers need thorough testing of new database-related changes, which can delay the release of new applications or features that other departments are pushing for.

In many cases, the non-functional requirements are not clearly identified and documented and are just left to the understanding and imagination of Database developers. Few of them: - Handling of null values - Data quality issues - Handling failures like Referential integrity - Handling Data volumes - Performance requirements

Ensuring that the "big picture" of the data ecosystem is accounted for, relies on the existence and access to the data strategy and standards/guard-rails around the architectures that are aligned to longer term data architecture goals. Getting database developers, database managers/DBAs aligned relies on some common ground in this space. At the end of the days, creativity from developers is to be encouraged but it friction is common when the data custodial groups are faced with new implementations where there input has not been sought. Communication is key to ensure engagement and ensuring there is alignment to strategies and a willingness to support newer technologies and approaches.

This is spot on. Infact in the industry no one talks about it. Most applications start with database designed by someone who is not a database professional since the application is in POC/demo/MVP phases to get its first client/funding/demo in the market. The target at that point of time was to get the app going rather than thinking in terms of optimization and scalability. A database system needs constant care and monitoring to make sure it scales well and doesn't break down when there is unprecedented load coming on. Some people who are not from the database background think performance tuning as a one time activity in a life time which is never true.

The database must reflect the business without inconsistency. The modeling must be aligned with business needs and have simple but well-structured maintenance.

En todos mis a?os de experiencia como desarrollador de SIstemas y Bases de Datos, no he tenido dichos conflictos ya que realizando un buen análisis y coordinación siempre hay formas de llevar a cabo cambios significativos y hay que tener muy en claro y en cuenta que una base de Datos tiene que ser altamente escalable y esa es la idea desde su concepción

Agreed! Continues changes after the base structure creation in database will take more time to adjust the database structure and an that will affect the code changes. That creeps the development

Define deliverables of project into phases. If the dedline is tight then maybe let the more complex tasks deliverables move into a phase 2, but where the investigations and work around it euns in parallel with phase 1.

We needed to build a system where the computer could auto-spend $ 24/7; and I would still have a job the following morning. A hands-on operations team explaining in laymen terms 'technical solutions' to a removed database coding team lead to gaps and misinterpretations. Programmers had no knowledge to identify good or bad data and processes. The solution was to move the "supply chain engineers" into operations and give them a pool of suppliers, parts and orders to manage. Conversations now freely shift back and forth between business processes, objectives and SQL code. The coding works because they have real-time feedback while coding and see how dirty real-world data plays out against their own assumptions, gaps and error handling.

Data Governance is a fantastic way to establish what happens with your raw data. In many instances importing data from a file or an api is necessary , please establish a simple table to place the data you import , this table can be all varchar data types , then the data is in your system being staged. Data Governance is going to allow you to manipulate that data to other tables through a utility like Atleryx, SSIS, or through SQL development. This methodology is essential for developing a data lake to be used for a data warehouse where your data marts will be developed. A solid foundation prevents the biggest headaches.

In my perspective Data Quality: Conflicts can emerge when different departments have varying standards for data quality and accuracy.

If the source of the data is for more than one department or existing computer system the linking of the data may be a challenge. For example, different departments may have different portions of data about each customer. However, in the database all this data needs to be linked. A common problem is that the way the customer is referred to differs between departments. Finding a way to accurately match the same customer across the departments so that a unique key can be assigned in the database is critical to the success of the database.

Garbage in garbage out. Spend a bit more time on cleansing initially which will save a lot of duplicated cleansing efforts by various users later.

Conflict between Database Developers and other departments often stems from differences in priorities, timelines, and perspectives. Developers may prioritize data integrity and performance, while other departments, such as marketing or sales, might prioritize quick access to information for analytics. Communication breakdowns, differing project timelines, and varying technical understanding can contribute to these conflicts. Balancing the needs of different departments and fostering clear communication can help mitigate such issues.

In my perspective It's essential to recognize and manage resource constraints effectively to ensure the successful development and maintenance of a database system. This may involve careful planning, prioritization, and potentially adjusting project scope to align with available resources.

This is true. Sometimes we do overcommit and that should be avoided. Specially in the case of performance tuning. Getting to the root of the issue where we get lag in performance and tuning it with the best way can vary from an addition of an index which might take few minutes to re-writing the code. It is very tricky to estimate that. Hence communication is key here when there are less developers on the team. Sometimes the hardware limitations should also be communicated well with proper documentation as the upgrade being the last resort along with list of things tried and why upgrade is the only way to get a better output.

No Concuerdo con ésta afimación ya que talvez dicho motivo de limitacion de recursos se daban hace 20 a?os atrás, no ahora con las capacidades de procesamiento que tiene los servidores, la velocidades de red a los que estamos ya acostumbrados y a la variedad y ligereza que damandan ahora los manejadores de bases de datos actuales. excepto claro si hablamos de procesamiento y/o integración de información para la obtención de KPIs o BD Olap ahi ya cambia un poco la cosa

Les bases de données, essentielles aux systèmes d'information, entrent fréquemment en conflit avec d'autres services pour l'allocation de ressources. Les développeurs de bases de données, nécessitant des quantités substantielles de mémoire et de puissance de calcul, peuvent impacter les performances d'autres services. Pour atténuer ces conflits, une collaboration étroite et des pratiques de gestion des ressources, telles que le dimensionnement adéquat des bases de données, sont cruciales. La résolution harmonieuse de ces frictions garantit la stabilité et l'efficacité globale des systèmes d'information complexes.

In my perspective In the realm of database development and analysis, technical challenges encompass managing large data volumes efficiently, designing accurate data models, optimizing database performance, integrating diverse data sources, ensuring data security, maintaining data consistency, implementing backup and recovery solutions, performing routine maintenance tasks, making informed technology selections, and managing versioning and change control. These challenges necessitate expertise, meticulous planning, and collaborative efforts to find effective solutions.

This happens mostly in the case of performance tuning. Some departments simply think that adding an index, a server restart, a hardware upgrade might solve the problem. There are many complexities involved which make the task complicated. DBA related tasks where the work is more on the administrative side, at times takes time which may be tricky to explain to other departments at times.

Desafío técnico talvez, conflicto no. Y es que la razón de ser de las áreas técnicas es la de servir con cada vez mejores herramientas a los usuarios que se encargan del negocio o rubro de la empresa. las demás áreas han de enfocarse en la buena información que desean obtener de su Base de datos y de sus Sistema y el área técnica debe encargarse de servir cada vez mejor sin importar la complejidad y otros asunyos que para eso es el área técnica

Technical challenges, such as integrating new technologies or adapting legacy systems, can lead to misunderstandings and conflicts. Non-technical departments might not fully grasp the complexities involved, leading to unrealistic expectations and pressures on the development team. Clear explanations and setting realistic expectations are key to managing such conflicts.

Fortunately, the IT world continues to converge technology more and more into intuitive, flexible, "plug and play" components. Many forms of new technology simply aren't tested extensively because the assumption is "it will work". Having said that, I will say "GBG". (God Bless Google). Any problem you encounter has likely been already resolved by someone around the world somewhere. In the last 10 years, I don't remember a single technical challenge that I wasn't able to resolve in a day or two.

We need to consider Data Access and Security: Departments may want different levels of access to the data, which can lead to conflicts regarding data security and permissions. Data Structure: Differences in how data is structured and stored can cause conflicts, especially when various departments have unique requirements. Performance: Database developers may need to optimize the database for performance, but other departments may prioritize ease of use, potentially leading to conflicts.

Data literacy. It's helpful when people have a basic understanding of database fundamentals such as relations, data types, transactions, etc.

Conflicts between database developers and other departments can arise due to differences in priorities, perspectives, and goals. Here are some common conflicts: 1.Data Structure and Schema Changes 2.Performance vs. Functionality 3.Data Security and Access Control 4.Data Quality and Validation 5.Change Management and Deployment 6.Communication Gaps 7.Resource Allocation 8.Technology Stack Preferences 9.Data Governance Policies 10.Reporting and Analysis Requirements

Integration with other technologies: The way SQL executors work is quite different from other technologies. This causes conflict with developers of other technologies. For example, Java. Few scenarios: 1) A query which performs well in SQL could cause memory issues in a Java application due to high volume of data returned. 2) A query which is automatically generated using a framework may not be performant and could be causing performance issues

Differences in the implementation of standards around Security: The way SQL technologies handle security like user management, Role based access control, data level authorization are different from other technologies like REST services, Data Analytics tools etc and could cause conflicts with security team and other teams while trying to standardize the security recommendation and implementation.