On Thu, 2025-03-06 at 12:15 +0330, me nefcanto wrote: > We had problems with cross-server queries on SQL Server and MariaDB too. > It seems that cross-server queries are not solved by any engine. But we > had no problem with cross-database queries. That's where it worked well > both on SQL Server and MariaDB. But then you always worked with a monolithic system. Splitting over several "databases" (we call them schemas) does not allow you to scale horizontally. > > Well, if you split the data into several databases, that *was* sharding. > > The way I understood it, sharding is when you split the database by rows, > not by tables. Examples choose a column like Tenant or User or Date as the > base of sharding. Never have I seen an example that stores Orders on one > database and Customers on another database and call it sharding. Right. And I don't think that your data model is good. It won't scale well, because you don't get more tables as you get more data. > But to choose a technology, we do have enough literacy and experience. > It's just some simple questions and answers. If I know that FDW works > differently for same-server databases, then I know that we will migrate. It doesn't work any differently. > > Don't ever store arrays in the database. It will be a nightmare. > > This is a very interesting claim. May I ask you to share its problems > and your experience? If you store foreign keys in arrays, you have no referential integrity, and any join over the array will be complicated and slow. If you store many values in an array and you want to update one of these values, you have to retrieve the whole array, construct a new array and store that. You cannot modify individual array elements, only the whole thing. Of course there are ways to use arrays that are not harmful. It's just that almost always when I see someone use an array as table column, it is an abuse of technology. Yours, Laurenz Albe
