Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

10 Business Lessons I Learned From Playing D&D

kpharmer Not in the role-playing games I played (257 comments)

While there was a bit of greedy butchery and mindless power-acquisition going on mostly what happened was story-telling, character development, working as a team, out-smarting opponents, building alliances, etc.

Grinding? In playing d&d, gurps, etc with a good group of people it *never* felt that way. We may have spent 2 years and never made it past 3rd level and struggled every step of the way - but it was a fun memorable time. Perhaps grinding happens more in computer-based "rpgs"? Or groups of kids that want nothing else than to have a 20th level character. Either way, in many years of playing I never really felt that.

about 5 years ago
top

Enthusiasts Convene To Say No To SQL, Hash Out New DB Breed

kpharmer Re:Pros & Cons of non-relational solutions (423 comments)

Large databases use a combination of range partitioning AND indexing. If you're lucky you've also got hash partitioning - to distribute your database across N servers. Partitioning is far more general and forgiving for purposes like this than indexing.

And creating trends in your application layer then storing them in logs can work, but:
1. you still rely on figuring out in advance what you're going to need
2. if you don't load those logs back into the relational database then you can't effectively join it to all that data. And you then either must log redundant data or have useless logs.
3. grep & sed or custom reporting code against your logs is a poor substitute for any standard reporting tool or custom code against your database.
4. database features like partitioning, indexing, parallelism result in in-database aggregates being faster than logs
5. did i mention automatic query rewrite? where the database automatically converts eligible queries against the base table to actually run against the summary tables...

about 5 years ago
top

Enthusiasts Convene To Say No To SQL, Hash Out New DB Breed

kpharmer Pros & Cons of non-relational solutions (423 comments)

Note that most of these solutions come from the interwebs, social networks, etc. And it isn't so much anti-sql as it is anti-relational database (sql != rdb).

The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads & writes, don't need to perform ranged queries / reporting /etc, and don't need ACID compliance. And that may be the case. Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.

On the other hand, ebay achieves scalability AND data quality with relational databases. And when I've worked with architectures that scale massively and avoid the relational trap for better solutions - they inevitably later regret the lack of data quality and complete inability to actually get trends and analysis of their data. It *always* goes like this:
    Me: So, is this thing (msg type, etc) increasing?
    Developer: No idea.
    Me: Ok, so lets find out.
    Developer: How?
    Me: I don't know - typical approach - lets query the database.
    Developer: It'll take four+ hours to write & test that query and then days to run. And when it's done we might find that we wrote the query wrong.
    Me: What?!?
    Developer: We had to do it this way, you can't report on 10TB databases anyhow
    Me: What?!? Are you on crack? there are dozens of *100TB* relational databases out there that people are reporting on
    Developer: well, we probably don't need to know what that trend is anyhow
    Me: I'm outta here

about 5 years ago
top

What Programming Languages Should You Learn Next?

kpharmer Re:SQL is next for me (759 comments)

> If you knew COBOL it would look familiar :)

Not really - you're thinking about stored procedure language. Which if you close one eye and squink with the other I guess could look a little COBOL-esque, that is without the column-orientation, section headings, etc.

SQL on the other hand looks like this:

SELECT dept.dept_name,
              per.rank,
              count(*) as personnel_rank_count
FROM dept_table dept
          INNER JOIN personnel_table per
                ON dept.dept_id = per.dept_id
WHERE dept.dept_type = 'internal'
GROUP BY dept.dept_name,
                  per.rank
ORDER BY 1,2
         

more than 6 years ago

Submissions

kpharmer hasn't submitted any stories.

Journals

kpharmer has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>