Libertalia is a Pirate themed board game designed by Paolo Mori, I first saw it played on Tabletop and thought it looked good fun yet not too complex. And after a couple of plays that still holds, with a few caveats.
Overview
The aim of Libertalia is to amass the greatest fortune over the last 3 weeks of your pirating career before you retire to Libertalia. Each player will have the same crew to send on quests every day, with more crew being made available at the end of the week. Inter player interaction comes from deciding what your opponents are going to use, and a few actions allow you to attack opponents.
What I enjoyed
The theme was really good, normally I’m not too much in to theme, but Pirates. For example the scoreboard is not a boring square but has crinkled edges and looks like an old treasure map. Whilst you had plenty of choice, for me there was little decision paralysis. Finally, it felt like you had agency over your outcome, by which I mean it didn’t feel like you can do well without playing well or vice versa.
What wasn’t so good
Having to pause for setup twice in the middle of the game really got in the way of the rhythm of the game, this could be slightly alleviated by getting the second and third week recruits lined up prior to the game - but you still need to reset everyone’s money, collect their loot and then put out loot for the next week.
This wasn’t an issue for me, but some people just didn’t get what was happening, they were mostly confused by the ordering in which things happened - this could have been down to my explanation but I also find it relatively confusing. This meant they just didn’t get what they should do and ended up playing randomly. Which has the side effect of damaging the game for the rest of us, but either fate was on our side or the game handles it well because it wasn’t too major an impact on the actual gameplay.
Would I recommend it?
Aye, I would. Though I would suggest watching the Tabletop video linked at the beginning (You needn’t watch all to get the gist of the game), or if you are able play someone else’s copy or get down to one of the many Board Game clubs, or one the few Board games cafés then I would highly recommend you try out Libertalia.
Welcome to the next exciting[1] instalment of Exploring SQL Server, in which we will have a very quick look at Filegroups and Partition Schemes.
[1] Excitement not guaranteed.
Isn’t it just one big file?
No, by default a SQL Server database requires at least two files the database and the log. For recovery reasons these should really be on separate disks. From here on out I’m just going to ignore the log file for simplicity’s sake.
By default you will have one database file, which is great until the database gets much larger and this will cause performance issues. OK, so I add a second file and I’ll just put a max file size on each. That works fine, the files will grow as needed and I can just add more files.
So why do I need Filegroups and Partitions?
The answer is if you want to group certain parts of the data in certain files or on certain drives. A filegroup is what it sounds like - it is a group of files, so you can talk about the group rather than an individual file - this means you can add/remove/change names of the files without affecting the objects in the database. When you create an object you can say which filegroup it should live in, so your stored procedures may live in a separate location to your tables and data.
You may want even more finegrained control of how the database is stored down to the data level, and this is where partitions come in. A partition is made of two parts a function and a scheme. The function says how to split the data (e.g. <1997, 1997,1998,>1998), and then you apply this to a table or index and say which filegroup each partition should reside in.
Why would I bother partitioning my tables?
If you are doing operations on distinct groups of data then you can just manipulate that file and not the file for the whole table. For example I wish to do something to all the rows before 1997, I can go straight to that partition and ignore everything from the other partitions gaining a performance boost because I don’t have to look at them or do anything to their on disk representations.
Hopefully this sheds some light on what filegroups and partitions are, and why you might want to use them.
Following on from my first post about Exploring SQL Server, I would like to talk about the things I learnt about how SQL Server handles users and permissions.
Surely a user is a user?
You would think so, but SQL Server has two types of user:
A Login:
A Login is what you can use to access the SQL Server instance and can either be your Windows account (or group) or a created User name and password.
Relates to what you can do to the instance (e.g. Creating databases or admin functions)
A User:
A User is scoped to a database, and is optionally linked to a login.
Relates to what they can do to the database (e.g. view it, view data, modify the schema)
Also you also have roles and server roles.
Each login can have multiple server roles.
Each user can have multiple roles (the roles are also scoped to the database)
Note that a (server) role can also have a different (server) roles in the same way users/logins can.
And how do i make use of users and logins?
Well you only allow certain users/logins to have certain actions. To help explain this I am going to bring in some terminology:
Principal: A user/login/role/server role
Securable: Something that needs protecting
Actions: Things that can be performed on a securable (create, modify, delete being the main ones)
Just the terminology should give a hint at how you do this, for each securable you give principals the ability to perform a set of actions they can perform and a set of actions they can’t perform.
Great, What can I secure?
Pretty much everything, from viewing data in a particular column to creating/deleting logins on the server.
Hopefully this sheds some light on how SQL Server handles Users, roles and permissions.
At Redgate we have a thrice yearly event, Down Tools Week. During which everyone has the choice not to work on their normal project but instead can work on another project of their own choosing. In the last Down Tools Week I chose to spend the time getting to know SQL Server.
Why did I do this?
Quite simply, Redgate works on products that look at SQL Server databases and I felt I had an insufficient understanding of SQL Server specifics. It felt like a good idea to spend a week focused solely on improving my knowledge.
What did I do?
Firstly I went and found some useful video tutorials on SQL Server and watched them. The best place I found for these (it was free which helped) was Microsoft Virtual Academy. I started with a refresher on SQL skills and ended with a how to administer a SQL Server. Whilst I did not go into full depth on any subject, which was never the intention, I did get a passing knowledge of many different areas.
What did I get out of it?
The main thing was a broadening of my database knowledge and a better understanding of where to go for more information. But what was this knowledge if I didn’t have some way of easily accessing the knowledge, either for myself or someone who doesn’t want to try and sift through any technical details but just wants broad strokes. So the final thing I did during Down Tools Week was to choose several areas to break down into business card sized cheat sheets.
I mainly picked areas which I had previously heard questions about and would not have been able to answer easily. The next few posts will be going through some of these sets of cards.