|
|
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Добрый день, Прошу совета, может кто подскажет. (В первую очередь люди, ненавидящие и хаящие EAV :) ) В данный момент проектирую БД, к которой есть такие требования: Блок 1. - Есть 4 вида сущностей. Суммарное кол-во их ~ 2000 - У сущностей есть переменное кол-во разнотипных(number, date, string) входящих и вычисляемых атрибутов. Атрибуты могут и будут активно добавляться пользователями. - Кол-во атрибутов для каждой сущности может достигать 1000 штук. Могут быть атрибуты статические (изменяются крайне редко), с привязкой к году, с привязкой к дате. - У атрибутов может быть default value - По значениям атрибутов пользователи будут строить фильтры для выборки сущностей Блок 2. Отдельно есть архив. Каждый день, в зависимости от входящих данных о сущностях, происходит пересчет атрибутов, привязанных к году, за всю историю (за каждый год) и сохраняется в архив. То есть в день в архив будет скидываться 2000сущ*1000атр*40лет = 80 млн значений атрибутов. Главная задача - быстро доставать значения атрибутов по выбранным сущностям за любую дату из истории. Вопросы: Блок1 - классическая схема EAV. Ничего придумывать не надо. Или есть вариант лучше/удобнее/быстрее ? Блок2 - Архив думаю хранить как денормализированную таблицу с полями CalcDate | Year | Entity_id | Attr_id | Attr_val_num | Attr_val_date | Attr_val_str партиционированную по CalcDate (получается ~10000 партиций) с локальными битмап-индексами по Entity_id+Year С таким кол-вом партиций оракел будет нормально работать? Как думаете, схема годная? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2016, 17:35 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамВопросы: Блок1 - классическая схема EAV. Ничего придумывать не надо. Или есть вариант лучше/удобнее/быстрее ? Блок2 - Архив думаю хранить как денормализированную таблицу с полями CalcDate | Year | Entity_id | Attr_id | Attr_val_num | Attr_val_date | Attr_val_str партиционированную по CalcDate (получается ~10000 партиций) с локальными битмап-индексами по Entity_id+Year С таким кол-вом партиций оракел будет нормально работать? Как думаете, схема годная? Можно брать EAV, можно другой вариант. Тут виднее тому кто разрабатывает и будет все это сопровождать. Можете посмотреть в торону кубов, как вариант. По ораклу не скажу, т.к. не считаю что знаю его на необходимом уровне для подобного рода советов. Да нам всеравно. Если разработчика устраивает - вперед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2016, 17:49 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Парампампам, Если у Вас никогда не будет стоять задача получить часть атрибутов по сущностям - можно рассмотреть возможность хранения значений атрибутов в BLOB-е в виде xml/json/..... (особенно для архива) Получить одну запись с blob-ом часто получается быстрее, чем считать на клиента resultset из 1000 мелких записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2016, 18:05 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
функциональную зависимость даных разных атрибутов одной сущности как будете контролировать? а зависимость между разными сущностями как будете? а требования интерфейса пользователя какие? сами пользователем поработает со своей системой? а как думаете, почему бы всем вендорам не заводиться на EAV или xml-блоб хранение ну а может и свой формат хранения, не? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2016, 20:04 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
автора как думаете, почему бы всем вендорам не заводиться на EAV или xml-блоб хранение А вендоры (все не все, но многие) поддерживают "XML-блоб хранение" уже лет 10 как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2016, 20:27 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, Часть атрибутов может вытаскиваться для постоения всяких графиков. Кроме того, очень редко, но возможен вариант апдейта одного атрибута по одной сущности за всю историю. Поэтому, xml-blob хранение не подойдет. babona, авторфункциональную зависимость даных разных атрибутов одной сущности как будете контролировать? а зависимость между разными сущностями как будете? Загрузились входящие атрибуты, потом посчитались вычисляемые, аналитики что-то откорректировали - и вся куча пошла в архив. зависимость между сущностями примитивная - одни сущности есть parent-ами других Про интерфейс пользователя и т.п. - вообще не понял, как он влияет на структуру БД :) У вас есть предложения/возражения или это просто мысли вслух? ) Я потому и спрашиваю, может кто-то имел подобную задачу, знает подводные камни или придумал хитрый финт ушами, который сильно помог или в хитром виде/структуре хранит данные и т.п. Кроме того, интересует насколько больно (и больно ли вообще?) для оракла таблица в 10 тыщ партиций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 12:07 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамКроме того, интересует насколько больно (и больно ли вообще?) для оракла таблица в 10 тыщ партиций . Если вы под этим подразумеваете записи (строки) таблицы БД - это вообще мелочь, даже для MySQL. О монстрах типа MS или Oracle и спрашивать не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 12:28 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Злой Бобр, Нет, я имею ввиду именно таблицу с 10 тыс партиций по 80 млн записей в каждой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 13:03 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Что то я не понял вашей математики Парампампам 2000сущ*1000атр*40летОткуда 40 лет? У вас уже есть история за 40лет? Вы уже сейчас задумываетесь о судьбе своей нетленки через 40лет? Парампампам партиционированную по CalcDate (получается ~10000 партиций) Откуда 10000? зачем вам вообще нужны партиции. Как вы будете их добавлять/удалять/чистить и т.д. Парампампам Могут быть атрибуты статические (изменяются крайне редко), с привязкой к году, с привязкой к дате. Зачем делать ежедневный слайс для статических атрибутов или атрибутов меняющихся раз в году? Парампампам Главная задача - быстро доставать значения атрибутов по выбранным сущностям за любую дату из истории.Бысто это как? Есть измеримые значения? Сколько планируется одновременных пользователей? Что вижу я из вашего путанного объяснения - у вас есть 2000 объектов четырех видов. У каждого объекта максимум 1000 полей. У вас есть выборки/фильтры/поиск сущностей. То есть ваши сущности УЖЕ лежат в неких таблицах (как минимум в головах у пользователей) к которым вы применяете фильтры. Будут ли эти таблицы реальные или служебные особого рояля не играет: хотите быстрый поиск = стройте и поддерживайте таблицы и индексы. Парампампам Атрибуты могут и будут активно добавляться пользователями.Мой небольшой опыт подсказываете, что атрибуты активно добавляются пользователями когда проектировщик не знает (по объективной или субъектной причине не суть важно) предметной области и вынужден "бить по площадям". После того как все устаканится пользователи не добавляют атрибуты , это делают программисты по запросу от пользователей ибо атрибуты не висят в воздухе, а нуждаются в обрабокте в прикладной программе. Парампампам Или есть вариант лучше/удобнее/быстрее ? Четыре таблицы с 2000 строк в сумме для поиска, остальное в EAV или XML (blob, json) Парампампам очень редко, но возможен вариант апдейта одного атрибута по одной сущности за всю историю. Поэтому, xml-blob хранение не подойдет.Почему не подойдет? Если это редко бывает то подождут. Парампампам Как думаете, схема годная? Похоже для себя вы уже все решили. Вперед на грабли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 17:33 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамБлок1 - классическая схема EAV. Ничего придумывать не надо. Или есть вариант лучше/удобнее/быстрее ? Единственной альтернативой EAV в данном случае, мне видится - расширяемые таблицы 1:1 к основной. Их может быть довольно много, в них может группировать атрибуты по вашему выбору, например, одна таблица со статисечкими атрибутами, вторая с часто обновляемыми, третья с историческими и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 17:55 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
SERG1257Откуда 40 лет? У вас уже есть история за 40лет? Вы уже сейчас задумываетесь о судьбе своей нетленки через 40лет? Есть история за 35 лет. Задумываюсь о судьбе нетленки в следующие 5 лет :) SERG1257Откуда 10000? зачем вам вообще нужны партиции. Как вы будете их добавлять/удалять/чистить и т.д. В году ~250раб.дней*40 лет=10 тыщ Добавлять автоматом = interval partitioning, удаляться/чиститься ничего не будет. SERG1257Зачем делать ежедневный слайс для статических атрибутов или атрибутов меняющихся раз в году? инвестиционный анализ, он такой анализ сохраняются исходные данные и результирующие для дальнейшего back-анализа SERG1257Бысто это как? Есть измеримые значения? Сколько планируется одновременных пользователей? Скажем так, несколько минут - приемлемо, 30 минут - нет. Всего - несколько десятков юзеров. SERG1257Мой небольшой опыт подсказываете, что атрибуты активно добавляются пользователями когда проектировщик не знает (по объективной или субъектной причине не суть важно) предметной области и вынужден "бить по площадям". После того как все устаканится пользователи не добавляют атрибуты , это делают программисты по запросу от пользователей ибо атрибуты не висят в воздухе, а нуждаются в обрабокте в прикладной программе. Поверьте, это не тот случай :) SERG1257Похоже для себя вы уже все решили. Вперед на грабли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 18:09 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамНет, я имею ввиду именно таблицу с 10 тыс партиций по 80 млн записей в каждой. С точки зрения MS SQL, если именно партиции (у мелкомягких это секции, поэтому сразу не сообразил о чем именно речь) - возможно до 15000 (на 2014 скуле). По Ораклу я думаю или почитайте мануал, или спросите в профильном разделе форума. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 18:30 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
автор, как будете контролировать ситуацию с данными по частм зависимости атрибутов? например, если клиент женщина и такого-то диапазона возраста, то может быть беременной; если клиент -мужчина и выше опред. возраста, то может быть военнообязанным, и если в.о., то иметь звание какое-то. Ну и куча таких зависимостей и среди полей разных таблиц. а как будете выкручиваться, когда есть ядровые поля, а есть такие, которых насоздавали в других, автономных копиях системы, а вам потом сводить воедино Ivan, который не такой уж дурак, вам дал дельный совет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 19:03 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Парампампам Скажем так, несколько минут - приемлемоНа достать атрибут по айди и времени? Или достать объекты со своими атрибутами согласно поисковому критерию. Парампампам Поверьте, это не тот случай :)Поверю. Вам лучше знать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 20:28 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Блок 1. - Есть 4 вида сущностей. Суммарное кол-во их ~ 2000 э это как ?либо 4,либо 2000, и что такое тип сущности? - Кол-во атрибутов для каждой сущности может достигать 1000 штук. уже однозначно EAV, в таблицах не бывает столько полей. Или надо произвести декомпозицию, разбить сущности на более мелкие. 1000 атрибутов как бы тоже намекает на то, что она не проведена - не может быть такое количество атрибутов у сущности. Отдельно есть архив. Каждый день, в ....дату из истории. ну, Olap бд к основной, EAV это как бы почти подразумевает. Вопросы: Блок1 - классическая схема EAV. Ничего придумывать не надо. Или есть вариант лучше/удобнее/быстрее ? нет. нету вариантов. EAV не классический ни разу. Блок2 - Архив думаю хранить как денормализированную таблицу с полями CalcDate | Year | Entity_id | Attr_id | Attr_val_num | Attr_val_date | Attr_val_str партиционированную по CalcDate (получается ~10000 партиций) с нет, не так, а как таблицу со всеми атрибутами в виде колонок. для этого нужна специальная СУБД, column store, у них ограничения на число колонок шире, гораздо. partition ing не нужен, у тебя не будет такого объемы данных, чтобы он был нужен, да и column store-ами он не поддерживается, потому что не нужен ни на фиг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 11:28 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
забыл дописать, еще конечно при загрузке нужно динамически менять схему, добавлять новые атрибуты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 11:29 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамЗлой Бобр, Нет, я имею ввиду именно таблицу с 10 тыс партиций по 80 млн записей в каждой. 800000 млн записей... те 800 миллиардов. ты в курсе, что таких баз данных в мире пока еще нет и не было? это много, такие объемы не то что орал, но и вообще немногие из существующих СУБД протянуть могут. ну и железо туда надо очень сложное, это надо где-то кластер из 100 машин делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 11:36 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Парампампам, Если у Вас Оракл не единственный "свет в окошке", напишите в личку. Вышлю материалы по EAV на базе NoSQL в среде СУБД Cache. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 12:38 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
работал в спектре от таблиц на 1K колонок до чистого EAV на вполне себе серьезных масштабах непонятно, сколько же актуальных объектов 2К или это только количество объектных типов? если 2К самих объектов - то не парицца ибо всего актуальных значений атрибутов 2M если нет - то огласите количество объектов пожалуйста (и да - для EAV поиск хотя бы по двум атрибутам - это соединение а не фильтрация) АРХИВ - НЕ НУЖЕН откройте для себя СЦД2+ и сделайте правильное секционирование и да - что же такое Year, чем он дополняет CalcDate? короче - основной вопрос по кардинальности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 18:35 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
йа забыл падпесаццо, аселАРХИВ - НЕ НУЖЕН откройте для себя СЦД2+ и сделайте правильное секционирование и да - что же такое Year, чем он дополняет CalcDate? короче - основной вопрос по кардинальности Как я понял ТС-а - у него есть 2000 сущностей по 1000 атрибутов с дополнительным измерением "год" с 40 значениями - т .е. реально 80 млн. значений атрибутов Т.е. есть сущность "пес шарик", у нее есть 1000 атрибутов "длина хвоста", "лохматость" и т.п. за 40 лет - "лохматость пса шарика за 1987 год = 11", "лохматость пса шарика за 1988 год = 12" + зачем-то ему надо пересчитывать значения всех атрибутов всех сущностей каждый день , т.е. сегодня мы рассчитали лохматость пса шарика за 1987 год в 11, а завтра - в 322455. Это звучит странно, но без подробного знакомства с задачей сложно что-то утверждать - т.е. видимо надо считать это как условия "дано:". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2016, 18:03 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, спасибо, котэ это получается временной ряд значений показателя, а может у него и другие измерения есть? а потом и модель показателя случится, а потом и алгебра на этом деле фантазировать можно долго, в любом случае, мы в конторе ТС зарплату за анализ и проектирование не получаем 80М (что там действительно вся история каждый день меняецца?) строк вполне можно на орацле без архива и секционирования ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2016, 16:27 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамАтрибуты могут и будут активно добавляться пользователями. Верный способ получить базу из которой ничего нельзя получить (каламбурчик-с!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2016, 12:19 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Cat2ПарампампамАтрибуты могут и будут активно добавляться пользователями. Верный способ получить базу из которой ничего нельзя получить (каламбурчик-с!) Активно надобавляют, каждый понимая под добавленным что-то свое, потом активно напишут запросы, потом активно перейдут в проектировщики БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2016, 19:20 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ПарампампамДобрый день, Прошу совета, может кто подскажет. (В первую очередь люди, ненавидящие и хаящие EAV :) ) В данный момент проектирую БД, к которой есть такие требования: Блок 1. - Есть 4 вида сущностей. Суммарное кол-во их ~ 2000 - У сущностей есть переменное кол-во разнотипных(number, date, string) входящих и вычисляемых атрибутов. Атрибуты могут и будут активно добавляться пользователями. - Кол-во атрибутов для каждой сущности может достигать 1000 штук. Могут быть атрибуты статические (изменяются крайне редко), с привязкой к году, с привязкой к дате. - У атрибутов может быть default value - По значениям атрибутов пользователи будут строить фильтры для выборки сущностей Блок 2. Отдельно есть архив. Каждый день, в зависимости от входящих данных о сущностях, происходит пересчет атрибутов, привязанных к году, за всю историю (за каждый год) и сохраняется в архив. То есть в день в архив будет скидываться 2000сущ*1000атр*40лет = 80 млн значений атрибутов. Главная задача - быстро доставать значения атрибутов по выбранным сущностям за любую дату из истории. Вопросы: Блок1 - классическая схема EAV. Ничего придумывать не надо. Или есть вариант лучше/удобнее/быстрее ? Блок2 - Архив думаю хранить как денормализированную таблицу с полями CalcDate | Year | Entity_id | Attr_id | Attr_val_num | Attr_val_date | Attr_val_str партиционированную по CalcDate (получается ~10000 партиций) с локальными битмап-индексами по Entity_id+Year С таким кол-вом партиций оракел будет нормально работать? Как думаете, схема годная? Вы обратились в раздел, который все еще называется "Проектирование БД", а не проектирование реляционных БД. Поэтому, нет - схема не годная для этой традиционной задачи. Вам совсем не нужно "партиционирование", EAV, "денормализованная таблица с полями", "архив". Используйте любую систему управления базами данных. В системах такого класса не может быть ограничений на "число колонок в таблице" или "длину записи". Поэтому используйте две таблицы - исходных данных и обработанных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2016, 10:07 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
БредятинаВы обратились в раздел, который все еще называется "Проектирование БД", а не проектирование реляционных БД. Поэтому, нет - схема не годная для этой традиционной задачи. . Годность схемы определяется теперь названием раздела, в который произошло обращение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2016, 23:30 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Cat2ПарампампамАтрибуты могут и будут активно добавляться пользователями. Верный способ получить базу из которой ничего нельзя получить (каламбурчик-с!) да, это правда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2016, 08:21 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
vadiminfoБредятинаВы обратились в раздел, который все еще называется "Проектирование БД", а не проектирование реляционных БД. Поэтому, нет - схема не годная для этой традиционной задачи. . Годность схемы определяется теперь названием раздела, в который произошло обращение. Нет. Наличие самого комментария определяется названием раздела. Не теперь, а всегда определялось. Нужно назвать раздел "Проектирование реляционных баз данных", и комментировать будет нечего. А только обсуждать проблемы)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2016, 09:57 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
БредятинаНет. Наличие самого комментария определяется названием раздела. Не теперь, а всегда определялось. Нужно назвать раздел "Проектирование реляционных баз данных", и комментировать будет нечего. А только обсуждать проблемы)) Если переименование раздела не приводит к годности схемы, как это прозвучало первоначально, то, видимо, следует признать само переименование разделов форума не достаточно эффективной методологией проектирования БД в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 16:14 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
vadiminfoБредятинаНет. Наличие самого комментария определяется названием раздела. Не теперь, а всегда определялось. Нужно назвать раздел "Проектирование реляционных баз данных", и комментировать будет нечего. А только обсуждать проблемы)) Если переименование раздела не приводит к годности схемы, как это прозвучало первоначально, то, видимо, следует признать само переименование разделов форума не достаточно эффективной методологией проектирования БД в целом. Нет. Наличие самого комментария определяется названием раздела. Не теперь, а всегда определялось. Нужно назвать раздел "Проектирование реляционных баз данных", и комментировать будет нечего. А только обсуждать проблемы)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 16:40 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Дежавю какое-то... Где-то я это уже читал здесь неск. лет назад. И с теми же участниками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 16:44 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
LSV, это будет повторяться долго, пока не переименуют раздел как предлагает Бредятина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 17:27 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
ViPRosLSV, это будет повторяться долго, пока не переименуют раздел как предлагает Бредятина Так он сам теперь отрицает свое предположение о влиянии переименования на "годность схем"? Т.е. ТСу переименование не поможет. И есть подозрение что никому. Поэтому менять, скорее всего, пока рановато. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 21:52 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
vadiminfoViPRosLSV, это будет повторяться долго, пока не переименуют раздел как предлагает Бредятина Так он сам теперь отрицает свое предположение о влиянии переименования на "годность схем"? Т.е. ТСу переименование не поможет. И есть подозрение что никому. Поэтому менять, скорее всего, пока рановато. Нет. Наличие самого комментария определяется названием раздела (комментарий появился только потому, что раздел называется "Проектирование БД", если бы он назывался "Проектирование реляционных БД", то комментария бы просто не было). Не теперь, а всегда определялось. Нужно назвать раздел "Проектирование реляционных баз данных", и комментировать будет нечего. А только обсуждать проблемы)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 19:42 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Годную схему каждый может, а вот ты попробуй сделать, чтобы "комментария бы просто не было". Ведь теория БД - это и есть: без комментариев.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 21:39 |
|
||
|
Есть ли альтернатива EAV? + организация архива.
|
|||
|---|---|---|---|
|
#18+
Представил как vadiminfo читает Цветаеву. Которая писала не просто на русском языке, а на самом русском, который только можно себе представить)) "Руки - и в круг перепродаж и переуступок!" или "Глыбами - лбу лавры похвал." И не просто читает, а еще и комментирует серьёзно)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2016, 14:14 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1540343]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
166ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 258ms |
| total: | 532ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...