так что противоречит

как ты достанешь данные из объекта в ооп?

Т.е. класс только с автосвойствами - норм

В F# полли и не нужен. Политики делаются очень просто на функциях высшего порядка

Sorry:) these are just few thoughts about few last topics in chat and I do not know ways to use cut-off in telegram

вали транслитом

Hi guys, Sorry for long post and some necroposting, but unfortunately I read chat only from time to time. @Dolfik : Firstly, looks like you should stay with your RDBMS. But I would recommend hiring a data platform developer because you are describing horrible things. Secondly, most of the problems you do have because of the nonoptimal design of data storages and data access layer. 69 joins could be okay in stored procedures which are preparing data for some reports. For instance, recent example - 200k LOC SP in SAS P&L report. And >100 fields could be okay in systems like MS Dynamics AX or MS Dynamics Nav but not in your case. In most systems optimal organization would be the following: a) use only stored procedures or their analog in your RDBMS for fetching data in appropriate format; b) physical storage of data will differ from returned data presentation; c) do appropriate normalization/ denormalization and physical layer optimization according to performance traces; d) this SPs will be used by your app DAL with data prepared for usage; e) modify data only by the same kind stored procedures, even maintenance operation should be done via service SPs; f) all data modification should write detailed logs - who, what and when (use date and time with offset information, also remember about collations); g) quite often a full snapshot of changed record could be used with log purpose; h) in the high loaded system with required low latency in dozens of milliseconds use async write; i) Consider transactional write of logs (i.e., in MS SQL Server it could be Service Broker); j) For search via changes and data you could use something like ELK or embed full-text search (if you have MS SQL Server); and data into this full-text search engine indexes you could write from logs queue (if you have snapshots there); in case of any changes in addition to search query change you could either change only newly added data or also alter old data as well; search queries could be stored as part of visualization engine (i.e., Kibana) or within RDBMS itself; k) one more time - performance traces is a mandatory thing; Example: online retail system >50k/sec changes of users' baskets >200k/sec users' baskets reading requests these operations are logical and change a lot of things within the system; real-time calculation of products stocks based on changes; these specific changes logs volume - around 1TB per month and many other requests to this specific server (system has much more components); MS SQL Server in VM, eight dedicated vCPU core and 32GB RAM, average CPU usage 15%-20% if you want to discuss more questions - do not hesitate to write me, I'll try to respond ASAP; Ayrat : About scale-up - there could be even machines with >2TB RAM and dozens of vCPUs. I.e., PDW, Oracle Exadata, IBM Netezza or IBM Z series mainframes. But it makes sense only for MPP systems with enormous data warehouses and the significant amount of reports. And hundreds or thousands of shards it is also okay but for the particular case. Speaking about Kafka - in most cases, it scales almost linearly. But as always you should consider how you would add and remove Kafka nodes dynamically and how you would spread it across your cluster of VMs. Typical proper Kafka usage - some data loss is affordable, and you need to process >1Gbps of data. Also, pay attention, if you have huge events messages, dozens of MBs, there could be some problems.

Короче, я вот работал с БД 2 ТБ инмемори 128 ядер + такая же реплика на чтение/фейловер. И короче, оно стоило конских денег. КОНСКИХ, КАРЛ

Wow, thanks

maybe on retirement, when NDAs end, I will write a lot of stories about these, i.e., contracts with IBM

Это ещё хуже :)

Короче, я вот работал с БД 2 ТБ инмемори 128 ядер + такая же реплика на чтение/фейловер. И короче, оно стоило конских денег. КОНСКИХ, КАРЛ

Hi guys, Sorry for long post and some necroposting, but unfortunately I read chat only from time to time. @Dolfik : Firstly, looks like you should stay with your RDBMS. But I would recommend hiring a data platform developer because you are describing horrible things. Secondly, most of the problems you do have because of the nonoptimal design of data storages and data access layer. 69 joins could be okay in stored procedures which are preparing data for some reports. For instance, recent example - 200k LOC SP in SAS P&L report. And >100 fields could be okay in systems like MS Dynamics AX or MS Dynamics Nav but not in your case. In most systems optimal organization would be the following: a) use only stored procedures or their analog in your RDBMS for fetching data in appropriate format; b) physical storage of data will differ from returned data presentation; c) do appropriate normalization/ denormalization and physical layer optimization according to performance traces; d) this SPs will be used by your app DAL with data prepared for usage; e) modify data only by the same kind stored procedures, even maintenance operation should be done via service SPs; f) all data modification should write detailed logs - who, what and when (use date and time with offset information, also remember about collations); g) quite often a full snapshot of changed record could be used with log purpose; h) in the high loaded system with required low latency in dozens of milliseconds use async write; i) Consider transactional write of logs (i.e., in MS SQL Server it could be Service Broker); j) For search via changes and data you could use something like ELK or embed full-text search (if you have MS SQL Server); and data into this full-text search engine indexes you could write from logs queue (if you have snapshots there); in case of any changes in addition to search query change you could either change only newly added data or also alter old data as well; search queries could be stored as part of visualization engine (i.e., Kibana) or within RDBMS itself; k) one more time - performance traces is a mandatory thing; Example: online retail system >50k/sec changes of users' baskets >200k/sec users' baskets reading requests these operations are logical and change a lot of things within the system; real-time calculation of products stocks based on changes; these specific changes logs volume - around 1TB per month and many other requests to this specific server (system has much more components); MS SQL Server in VM, eight dedicated vCPU core and 32GB RAM, average CPU usage 15%-20% if you want to discuss more questions - do not hesitate to write me, I'll try to respond ASAP; Ayrat : About scale-up - there could be even machines with >2TB RAM and dozens of vCPUs. I.e., PDW, Oracle Exadata, IBM Netezza or IBM Z series mainframes. But it makes sense only for MPP systems with enormous data warehouses and the significant amount of reports. And hundreds or thousands of shards it is also okay but for the particular case. Speaking about Kafka - in most cases, it scales almost linearly. But as always you should consider how you would add and remove Kafka nodes dynamically and how you would spread it across your cluster of VMs. Typical proper Kafka usage - some data loss is affordable, and you need to process >1Gbps of data. Also, pay attention, if you have huge events messages, dozens of MBs, there could be some problems.

Мне кажется, самый фейл случился, когда выбрали структуру table per class

Прохладная история

документация только юзерам (т.е. тем кто поставляет евенты), тем кто потребляет - хер лысый

https://translit.net/

you need to have a contract which includes documentation as well) but it costs a lot

Мы были потребителями очень древнего фида, мейнтейнеры древних технологий с другой стороны знали ещё меньше нашего как оно работает

ну ладно, в xml

Проект Объект Титул Вид документации Часть Версия изменений Документ 1 Документ 2 (содержит данные из документа 1) Документ 3 (содержит данные из документов 1 и 2)