• Skip to main content
  • Skip to primary sidebar

DallasDBAs.com

SQL Server Database Consulting

  • Services
  • Pocket DBA®
  • Blog
  • Testimonials
  • Contact
  • About

syndicated

Top 10 Careers in Data

February 13, 2025 by Kevin3NF Leave a Comment

Would you re-order these?


Machine Learning Engineer $$$$$

  • Develop and deploy AI models

  • Optimize machine learning algorithms for efficiency

  • Work with big data frameworks to process large datasets

Data Scientist $$$$$

  • Build predictive models and machine learning algorithms

  • Analyze large datasets to identify trends and insights

  • Communicate findings to stakeholders and guide business decisions

Data Engineer $$$$

  • Design, build, and maintain data pipelines

  • Optimize databases and data warehouses for performance

  • Ensure data integrity, security, and accessibility

Data Architect $$$$

  • Design enterprise data infrastructure

  • Ensure scalability and security of data systems

  • Define best practices for data management

Database Developer $$$$

  • Design, develop, and optimize database structures (tables, indexes, constraints)

  • Write and tune SQL queries, stored procedures, and functions

  • Integrate databases with applications and ETL processes

Database Administrator (DBA) $$$

  • Manage, maintain, and secure databases

  • Optimize performance and ensure high availability

  • Handle backups, disaster recovery, and troubleshooting

Business Intelligence (BI) Developer $$$

  • Design and maintain BI tools and dashboards

  • Integrate data from multiple sources for reporting

  • Optimize data queries for performance

Data Analyst $$$

  • Interpret and visualize data for reporting

  • Query and clean datasets for analysis

  • Provide business insights based on data trends

Data Governance Specialist $$$

  • Ensure data compliance with regulations (GDPR, HIPAA, etc.)

  • Define and enforce data policies and standards

  • Monitor and improve data quality

ETL Developer $$$

  • Build and manage Extract, Transform, Load (ETL) pipelines

  • Optimize data movement between systems

  • Ensure data quality in integration processes

 Check out Brent Ozar’s 2025 Salary Survey Results here

 The Bottom Line:

The world revolves around data, from your banking info to crypto to your Fortnite stats and Spotify playlists. There will always be jobs available to wrangle that data.

Filed Under: Career, SQL Tagged With: syndicated

Degrees and Trade Schools

May 8, 2024 by Kevin3NF Leave a Comment

Can we normalize a couple of things?

1 – Trade Schools. Back in the 80’s trade classes in high school and post high school were frowned upon, or looked down upon. Is that still a thing? It shouldn’t be.

I’ve had to rely on the expert skills of roofers, a plumber, HVAC experts, an electrician and auto mechanics all in the last 3 months. Every one of them was expert level in the trade as well as customer service.

2 – Not requiring degrees for non-degree level work.

Case in point, DBA work. If you have technical aptitude and a desire to learn, you can be a great DBA. I have three people on my team that came into IT as DBAs. Not the normal route, but its working just fine.

I get that degrees are a resume filter…but you miss out on amazing people that way.

Let me hear your thoughts!

 

–Kevin

Filed Under: Career, EntryLevel Tagged With: syndicated

3rd Party Applications Have Issues

May 2, 2024 by Kevin3NF Leave a Comment

As a SQL DBA, what do you do when a vendor application has performance problems that are code related?

Server settings don’t generally seem to be an issue.

Queries and vendor code…total hands off. I just point at code and say “There’s a great choice for optimizing in your next update!”

Indexes are the “Sticky Bits” in between client data and vendor code.

Seems like we get 30 indexes, or zero. Neither is usually right.

I get it…how do you tune an app for every possible use case for any client that may install it?

I always have my client get the official rules from the vendor. We don’t want to break an upgrade, or void a support agreement.

In some cases we’ve had to “Don’t Ask, Don’t Tell” our way into a solution with undo/redo scripts for very necessary indexes.

What do you do when tuning a 3rd party app?

 

— Kevin

Filed Under: Index, Performance, SQL Tagged With: syndicated

Set-Based vs Row-Based Database Code

December 1, 2023 by Kevin3NF Leave a Comment

In SQL Server, the terms “set-based” and “row-based” refer to different approaches or styles of writing SQL code to manipulate data. These styles have implications for performance, readability, and the way queries are processed. Let’s explore the differences between set-based and row-based code:

  1. Set-Based Code:
    • Operations on Sets: Set-based code focuses on performing operations on entire sets of data rather than individual rows. This is aligned with the relational nature of databases, where data is stored in tables.
    • Declarative: Set-based code is often more declarative, meaning you specify what you want to achieve without explicitly instructing how to do it. SQL is designed to work with sets of data, and set-based operations leverage this design.
    • Performance: Set-based operations are generally more efficient because they allow the database engine to optimize the query execution plan. The database engine can decide the most efficient way to retrieve and process the data.
  2. Row-Based Code:
    • Operations on Individual Rows: Row-based code, on the other hand, involves operations that are performed on individual rows one at a time. This style of coding is more procedural and might resemble how you would approach data manipulation in a programming language like a procedural language (e.g., C# or Java).
    • Imperative: Row-based code is often more imperative, specifying the step-by-step instructions to achieve a particular result. It may involve using cursors or loops to iterate through individual rows.
    • Performance Concerns: Row-based operations can be less efficient, especially when dealing with large datasets, as they might lead to more I/O operations and additional processing overhead.

Example:

Consider an example where you want to update the prices of all products in a certain category. A set-based approach would involve a single UPDATE statement that modifies all relevant rows at once:

UPDATE Products
SET Price = Price * 1.1
WHERE CategoryID = 2;

In contrast, a row-based approach might involve using a cursor to loop through each row and update it individually, which could be less efficient:

DECLARE @ProductID INT, @Price DECIMAL;

DECLARE ProductCursor CURSOR FOR
SELECT ProductID, Price
FROM Products
WHERE CategoryID = 2;

OPEN ProductCursor;

FETCH NEXT FROM ProductCursor INTO @ProductID, @Price;

WHILE @@FETCH_STATUS = 0
BEGIN
    SET @Price = @Price * 1.1;

    UPDATE Products
    SET Price = @Price
    WHERE ProductID = @ProductID;

    FETCH NEXT FROM ProductCursor INTO @ProductID, @Price;
END;

CLOSE ProductCursor;
DEALLOCATE ProductCursor;

In general, it’s recommended to use set-based operations whenever possible in SQL Server as they are usually more efficient and better aligned with the relational database paradigm. However, there may be cases where row-based operations are necessary or more practical, such as when working with procedural code or handling complex business logic that is not easily expressed in a set-based manner.

Thanks for reading!

Kevin

Follow @Dallas_DBAs

Filed Under: Performance, TSQL Tagged With: syndicated

Database Concerns – A Poll!

October 25, 2023 by Kevin3NF Leave a Comment

What are you most concerned about in your database platforms?

Please pick from the list below, and expand on your choice in the comments if you like:

Pick up to 3

View Results

Loading ... Loading ...

 

Thanks for reading!

Kevin

Follow @Dallas_DBAs

Filed Under: Uncategorized Tagged With: SQL, syndicated

SQL Server Backups are Not a High-Availability Solution

October 17, 2023 by Kevin3NF Leave a Comment

Please continue doing your backups!

Backups are Disaster Recovery, yes…but not HA.

Some will argue with this (in the comments most likely), but I broadly define “High Availability” as a system that can recover in seconds or minutes at most. Sometimes that is automatic, sometimes manual.

Backups might be quick to restore IF they are small enough and the right people are in place (not at lunch or otherwise out). But automated restores to prod just aren’t a thing.

SQL Server has this cute little marketing term called “Always On” which is nonsense. Always? Really? 9 Nines?

Always On covers both Failover Cluster Instances and Availability Groups. There are significant differences between the two. Both depend on the O/S Cluster…and they diverge a LOT from there. They are both HA.

Log Shipping (ancient tech) is great for DR and hitting your RPO number, but failover to a log shipped copy is manual.

Replication is not and never will be an HA or DR solution. Some things cannot be replicated, so they are lost if the publication database goes poof.

There are of course things outside of SQL Server that can help you hit your RPO/RTO goals. Feel free to share them.

What are you using for your HA solution?

Thanks for reading!

Kevin3NF

Follow @Dallas_DBAs

Filed Under: backup, HADR, SQL Tagged With: syndicated

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to page 5
  • Go to page 6
  • Interim pages omitted …
  • Go to page 13
  • Go to Next Page »

Primary Sidebar

Search

Sign up for blogs, DBA availability and more!

Home Blog About Privacy Policy
  • Home-draft
  • Blog
  • About Us

Copyright © 2025 · WordPress · Log in

 

Loading Comments...