January 1, 2012 at 6:45 am
we the development team in our project works both in dot-net and SQL server.
I am encouraging people here to have a separate team for SQL Server.
Can you please give me more justifications that why should we need it.
Appreciating your help.
i guess some like
1. Technology itself and so, people's expertise in that , which helps the project.
2. Perspective of the developer is different (more concern about performance, data-discrepancy,...)
January 2, 2012 at 12:12 am
I rarely see .NET (or Java for that matter) developers who are good at databases. Most of them tends to lack the set oriented mindset which often is required to create efficient SQL code. So, I would definitely prefer having two teams. Beware though, the database and .NET guys would often like to have things done in different ways. The .NET folks seems to love entity framework and similar technologies, but I hate technologies which seemingly cannot perform set based updates.
January 2, 2012 at 12:57 am
It depends of the experience of your dev teams with regards to :
- data analysis
- data documentation ( especially uniformity of data declaration )
- normalization process
- dealing with large numbers of data ( partitioning, ..)
- replication technologies
- HA technologies
- design of nice tight security
- monitoring
- working out a working DRP ( including actually performing the procedure )
- handling performance troubleshooting
- indexing strategies
- teaching set based approach to their peers/team members
- helping out in stead of being a competitor
- .... being a PITA of it comes to complying to guidelines and rules.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
January 2, 2012 at 1:25 am
It also depends upon your DEV Environment (your organization). Sometime projects timelines do not allow borrowing expert resources from free pool or different projects so Management continue with ‘One Man for All’ approach.
I have to agree with Johan that it depends on maturity & skills of DEV team as well. However it’s difficult to find good SQL developer (in .Net or Java team) but it’s possible. I have seen both the scenarios where .Net programmers were writing such a fantastic code that probably SQL developer might not think of. On the same time few developers write SQL to kill database (for example, Entity Framework, as okbangas pointed out).
If DEV team gets proper training / mentoring, I don’t see any harm in let them writing SQL programs. If you are really suspicious about quality deliverables, a short term review can be arranged with experts (& that should not be difficult for management).
January 2, 2012 at 4:48 am
A point I used to convince the people in my office was the .net developer mindset is not tuned to think of data but the actual logic being implemented. Therefore the code written is usually fine to implement the logic the business needs but the data tier soon becomes a bottle neck due to badly designed databases and poorly performing queries.
Additionally the data tier is gonna be around far longer than the website and since its a persistent medium your going to have to spend much more to refactor it later on.
A team which focuses on databases and data in particular will save the company a ton of money when they decide to have any of the following later on
New to move geographies (multi tenancy )
Tie up with a vendor or be acquired by another ( data integration)
Move to enable decision support ( Business intelligence)
Protect the customers and the business. ( data security)
Implement complex solutions quickly and the right way.
January 2, 2012 at 5:22 am
New to move geographies (multi tenancy )
Tie up with a vendor or be acquired by another ( data integration)
Move to enable decision support ( Business intelligence)
Protect the customers and the business. ( data security)
Implement complex solutions quickly and the right way.
- dealing with large numbers of data ( partitioning, ..)
- replication technologies
- HA technologies
- design of nice tight security
Jayanth & Johan, I have to agree with you on above points because they are database specialized jobs. My comments below were addressing simple SQL development tasks. It's obvious you won't ask a DB developer to write ASP.Net web component (or vice versa). If we look into the tasks that DEV team performs, we can find some tasks that fall in INTERSECT. I was referring just those tasks.
Specialized tasks should be performed by specialized team only and there is NO argument on that.
January 2, 2012 at 5:56 am
i would say , if dedicated Sql team is not possible then you can ask for some sql skilled resources who can assist the developers in
complex sql writing
tuning and optimization
better/clean code standards or style
walk through or code reviews
data migration support
or any support required by dev in sql side
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
January 2, 2012 at 10:23 am
Keep in mind my comments are not that devs are by definition not suited to handle sqlserver stuff !
I know devs who do their stuff very well with regards to sql and sqlserver.
Unfortunately, one cannot just accept they do by default.
With a small amount of data, you may get away with a sloppy model.
But small is relative, so it can go bad fairly soon, depending on the kind of mishaps that happened during your development cycle.
Best is to do the math !
Invest in a decent data model, at least 3NF for OLTP !!
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
January 2, 2012 at 12:30 pm
DBA Rafi (1/1/2012)
we the development team in our project works both in dot-net and SQL server.I am encouraging people here to have a separate team for SQL Server.
Can you please give me more justifications that why should we need it.
Appreciating your help.
i guess some like
1. Technology itself and so, people's expertise in that , which helps the project.
2. Perspective of the developer is different (more concern about performance, data-discrepancy,...)
If you really want justification, just look at the questions asked on these very forums. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2012 at 8:19 pm
I think having a SQL team is an excellent idea.
An even better idea, in my humble opinion, is to integrate SQL developers into your existing development team and then cross-train. This should be easy to sell to your .NET developers: a .NET developer with SQL skills is twice as marketable as a .NET developer with none.
Just my two cents. 🙂
January 3, 2012 at 2:14 am
Depends on the size of the development team. From experience, you need one dedicated for every 6-10 developers depending on how much they rely on SQL. If the team is smaller you generally dont need a dedicated dba but you will need at least one developer who is skilled in SQL or a DBA who can code!
January 3, 2012 at 4:56 am
There's also a matter of timing here. I've found that if you start the database development before you start any of the front end development, you end up with a much more correctly designed database that works well and tends to be much more scalable.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2012 at 5:07 am
Jeff Moden (1/3/2012)
There's also a matter of timing here. I've found that if you start the database development before you start any of the front end development, you end up with a much more correctly designed database that works well and tends to be much more scalable.
Very true. At least 5 days head start depending on the upfront requirements already being gathered. In an agile way, the requirements can then be expanded and added to during development based on a good upfront design.
In some companies I've found the bad practice opposite. Some tables have been directly linked to the fields on a form rather than correctly modelled. If they were on a single form, they went into one table.
January 3, 2012 at 6:15 am
MysteryJimbo (1/3/2012)
Jeff Moden (1/3/2012)
There's also a matter of timing here. I've found that if you start the database development before you start any of the front end development, you end up with a much more correctly designed database that works well and tends to be much more scalable.Very true. At least 5 days head start depending on the upfront requirements already being gathered. In an agile way, the requirements can then be expanded and added to during development based on a good upfront design.
In some companies I've found the bad practice opposite. Some tables have been directly linked to the fields on a form rather than correctly modelled. If they were on a single form, they went into one table.
Agreed... a single table for each screen where all integer columns were BIGINT, all character based columns were NVARCHAR(4000) or NVARCHAR(8000), and little, if any, concept of what normalization is (multiple phone numbers and addresses in the Customer table, for example).
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2012 at 6:24 am
Jeff Moden (1/3/2012)
MysteryJimbo (1/3/2012)
Jeff Moden (1/3/2012)
There's also a matter of timing here. I've found that if you start the database development before you start any of the front end development, you end up with a much more correctly designed database that works well and tends to be much more scalable.Very true. At least 5 days head start depending on the upfront requirements already being gathered. In an agile way, the requirements can then be expanded and added to during development based on a good upfront design.
In some companies I've found the bad practice opposite. Some tables have been directly linked to the fields on a form rather than correctly modelled. If they were on a single form, they went into one table.
Agreed... a single table for each screen where all integer columns were BIGINT, all character based columns were NVARCHAR(4000) or NVARCHAR(8000), and little, if any, concept of what normalization is (multiple phone numbers and addresses in the Customer table, for example).
Yup... comma separated or pipe separated columns. And within few days of development / maintenance they will come back to SSC & ask ‘I have CSV columns, please help me in getting in a table’.
Indirectly, we will sell String Splitter. 😎
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply