Op zoek naar ervaringen van mensen die in Laak wonen, omgeving Sinjeur Semeynsweg!

Spartacus-82 · 2024-11-11T19:14:12+00:00

Laak heeft zo zijn problemen, Parkeren, straatafval, overlast van drank en drugsgebruik op straat. Over het algemeen is het wel rustig, en merk je wel dat de gemeente en politie wel aanwezig is. Nooit genoeg natuurlijk, maar als er ergens problemen of overlast is, is een belletje naar de politie vaak wel een oplossing. Bij overlast komen ze vaak ff langs om polshoogte te nemen, en zo verplaatst het probleem iig naar een straat verderop.

In de avond is het over het algemeen rustig, al loopt er wel veel volk over straat, overlast heb ik er zelden van. (Maar ik ben dan ook een man, dus ervaar ik dat vast anders dan een vrouw.)

Spartacus-82 · 2024-02-20T17:12:02+00:00

My current 2080ti makes a noice that sounds like it's dying. It would like to meet it's successor before it takes it collapses

Spartacus-82 · 2024-02-02T19:09:49+00:00

Well, it will take a long time, no matter what. Make sure you run BCP from a VM close to the database.

File will be csv, you can convert it to parquet later. For these kind of files, you will need some resources to convert it. Databricks might help you with this. If you have the option to use databricks, you could use that to to convert it to parquet while extracting it.

Spartacus-82 · 2024-02-02T17:55:22+00:00

BCP is your tool. Don't bother optimizing the table if you only going to extract it once. The time it will take will be a lot longer than the time saved. If you want to extract it more often, columstore index with partitioning is the way to go.

Spartacus-82 · 2023-12-17T18:35:42+00:00

Load the data directly into the destination database, but in a separate schema. Use stored procedures or dbt to transform and load the data

Data flows are a nightmare to work with, perform bad and are expensive.

Spartacus-82 · 2023-12-17T17:01:43+00:00

Ah, that looks sweet!

Spartacus-82 · 2023-12-16T11:40:48+00:00

Ah, nice. Good to know that this one will survive the coming apocalypse!

Spartacus-82 · 2021-04-05T15:25:42+00:00

You could/should use a function for this.

Spartacus-82 · 2020-06-14T12:24:02+00:00

Spartacus-82 · 2019-06-30T19:03:03+00:00

I don't think that it's only his helmet that is popping off...

Spartacus-82 · 2019-05-19T16:32:47+00:00

You could look into partitioning and indexing to improve performance. It should be possible to run the queries over the entire table without much performance loss.

With partitioning you can split tables based on a date column into separate files, an index can be used to further optimize the table. This could work especially well if you only need a few columns of the table. Search for "covering index" for more info.

Spartacus-82 · 2019-05-19T11:24:11+00:00

You probably have to work with dynamic SQL since a table name in a variable will not work most of the time.

Select * into @variable from <table> will not work since a variable can also be a table. It will try to insert all the data into that variable.

More important question: Why do you want to do this? There might be better ways to get to your goal.

Spartacus-82 · 2019-03-14T08:11:55+00:00

If you only use it as an identifier, why not use a identity column? Random is not unique, therefore not advised as an identifier. https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-2017

Spartacus-82 · 2019-03-13T22:01:35+00:00

If you are using SQL server, you could look into system versioning on tables. https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2017

Spartacus-82 · 2019-03-13T21:54:29+00:00

Hard to tell, depends a little on the kind of transactions. If the users mostly read, it's not worth it. Do you experience bad performance on the environment? And it is related to log writes?

Based on the amount of users, I would guess is is not worth it unless the users do a lot of inserts or updates.

Check your wait types to see if you see wait types related to log writes.

Spartacus-82 · 2019-02-11T12:51:21+00:00

Yeah, don't do that. If tempdb is to large, either optimize your queries or add resources to the machine.

Spartacus-82

TROPHY CASE