• Поможет ли переустановка Windows при bad блоках на жестком диске?

    @Akina
    Понятие bad block очень широкое. Какой именно тип имеется в виду? А то ведь ошибочно помеченный в файловой системе - это тоже BAD... а для его излечения переустановки не требуется.
    Написано
  • Как найти общие поля в таблицах?

    @Akina
    Rsa97, ну не то чтобы ID - но с одной стороны по-хорошему поле-кандидат должно быть хотя бы уникальным.
    Написано
  • Как сделать так, чтобы устройства видели друг друга в сети Wi-Fi через хот-спот?

    @Akina
    МФУ подключен через Wi-Fi

    Тогда цепляй клиентов прямо за МФУ, зачем тебе посредник-то?
    Написано
  • Как найти общие поля в таблицах?

    @Akina
    Как раз USING у него не стрельнёт - судя по описанию, там наименования полей вообще берутся с потолка.
    Написано
  • Как сделать так, чтобы устройства видели друг друга в сети Wi-Fi через хот-спот?

    @Akina
    Не факт... Винде запросто хватит ума по умолчанию настроить хотспот в изолированный режим.
    Написано
  • Как сделать так, чтобы устройства видели друг друга в сети Wi-Fi через хот-спот?

    @Akina
    нужно чтобы подключённые по фай фай к основному нотубуку(1) ноутбуки видели МФУ

    Ну вот опять... МФУ локально подключен по USB к ноуту и расшарен? к другому компу в проводной сети и расшарен? подключен к проводной сети своим сетевым интерфейсом, и кем-то расшарен? подключен к проводной сети своим сетевым интерфейсом, и доступ нужен прямо к нему? если да - какой именно доступ, по какой технологии (LPR, web, прочее)?
    Написано
  • Как найти общие поля в таблицах?

    @Akina
    Сначала получаете сведения о полях - тип данных, размер. Составляете совместимые пары. Для каждой пары получаете количество уникальных значений по отдельности и совпадающих из них. Формально поле для связывания - это поле, где количество совпадающих как минимум 75% от общего, оптимально для хотя бы одной стороны 100%.
    Написано
  • Как сделать так, чтобы устройства видели друг друга в сети Wi-Fi через хот-спот?

    @Akina
    Как сделать так, чтобы эти устройства видели друг друга в сети?

    Что именно вы имеете в виду под термином "видеть"? наличие МАС в в ARP? прохождение пинга? доступ к опубликованному ресурсу или сервису? видимость в сетевом окружении? прочее?
    Написано
  • Чем отличаются сетевые коммутаторы?

    @Akina
    Если вам закупить горку железа на пару десятков миллионов с договорами обслуживания и обязательствами замены в течении суток - HP до санкций выигрывал.

    Ну с учётом разницы в цене - дешевле закупить двойное количество DLink-ов. Опять же свой техник дойдёт и заменит умершую железку быстрее, чем то же, но от вендора. Плюс хранение подменного фонда куда как дешевле договора обслуживания. Да и не сказать что такие коммутаторы мрут как мухи, уж больно дубовые они.
    Написано
  • Датаграмма UDP может прийти в неверном порядке. Как это?

    @Akina
    Если речь об ОДНОЙ датаграмме из 6 символов - то такое вряд ли возможно.
    Написано
  • Сколько обращений к базе данных происходит в данном коде?

    @Akina
    Не менее двух.

    Первое обращение - от connectdbpdo()->prepare, которое вызывает выполнение PREPARE statement.
    Второе обращение - от $r->execute, которое вызывает выполнение EXECUTE statement.
    В принципе будет выполнено ещё и третье обращение - для выполнения DROP PREPARE statement. Но уже за пределами показанного кода. В криво написанной программе это произойдёт по факту закрытия соединения или даже по факту его тайм-аута.
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru,
    Так нет никакого конкретного места, оно еще неизвестно, как неизвестно даже само наличие товара.
    Это же просто абстрактные конструкции, а не конкретные данные.

    Вот вроде правильно сказал - это абстрактные конструкции... и прям вот тут же про какое-то конкретное место.

    Я такого в даже очень крупных проектах еще не встречал.

    Наверное, потому, что они реализовывают весь комплекс. Товарный учёт, материальный учёт, финансовый, двойная булгахтерия и т.п. А это совсем другая предметная область и другой анализ. И да - вы сейчас говорите о внешней, интерфейсной, стороне, или погружались в структуру хранения и обработки и именно там нашли разные таблицы?

    У вас хоть склад и магазин - это одна сущность, но в зависимости от атрибута типа они будут отображаться на разных формах, в разном виде, с различным набором возможных операций... а вот перемещение товара в таблице будет выполняться совершенно одинаково, одним и тем же SQL-запросом с одними и теми же выражениями, и неважно, источник склад и получатель магазин, или наоборот.
    UPDATE goods SET Place_ID = @new_place WHERE goods_id in ( {list} );
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    имеется ввиду, что склад - это независимая сущность, аналогично и магазин.

    По-моему, вы неправильно понимаете, что такое "сущность" с точки зрения реляционной модели. У вас и то, и другое - одна и та же сущность "место, где находится товар". Просто они имеют различные атрибуты и методы, которые определяются типом (атрибутом) конкретного экземпляра сущности.

    Например, для подсчёта общего количества некоего товара придётся делать два подзапроса с абсолютно одинаковой логикой - к магазинам и к складам,- потом объединять их через UNION, потом агрегировать, и от магазина/склада в итог не попадает ничего. И вот этот промежуточный UNION - ещё одно свидетельство в пользу того, что две разные таблицы хранят одну и ту же сущность.

    Склад стал атрибутом товара, т.к. именно товар - это квант?

    Есть сущность Место (склад или магазин). Есть сущность Товар. Эти две сущности связаны как M:N, то есть имеется juncion table.

    Квант товара - это неделимый квантификатор атрибута Количество сущности Товар. Упаковка из 6 бутылок кваса. Мешок сахара весом 50 кг. И т.п. - то есть то, мельче чего экземпляр сущности Товар не дробится, и то, чем количество экземпляров учитывается. То есть атрибут сущности Товар, не подлежащий дальнейшему делению, его учётная единица в системе. То есть палетта с 20 мешками сахара - это не квант. Хотя 20 мешков сахара могут быть объединены в надгруппу Палетта - но она не будет являться экземпляром сущности Товар. Её могут поделить на две по 10 и отправить в разные магазины. А вот резать мешок и отсыпать полкило никто не станет.

    на уровне сущностей обязана быть комбинация товара со складом

    Пара (Товар-Место) - это связь типа M:N. Эта связь даже может иметь свои собственные атрибуты. И в этом случае она даже может интерпретироваться как самостоятельная сущность, хотя в данной схеме я полагаю это излишним.
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru, ?? Шо б я понял, что такое "работать со складами и магазинами".
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru,
    а если учитывать, что магазин и склад - это совершенно разные физические объекты с совершенно разными задачи, где общее только то, что кокнретный товар только хранится?

    Да хоть в космос запусти. Это не влияет вообще ни на что. От слова "совсем".

    у нас есть:
    1. Множество магазинов
    2. Множество складов
    3. Множество товаров
    И, соответственно, куча комбинаций экземпляров одной сущности с двумя другими.

    Есть Товар. Наименование там, характеристики и прочее. Это не более чем описание. Есть квант (неделимая порция, единица) товара - вот именно они хранятся. И каждый квант Товара может соответствовать (храниться) только одному Месту хранения (складу или магазину). Так что никакой кучи комбинаций нет и в помине. Может для квантов Товара существовать надгруппа Партия товара - с целью уменьшения количества записей, но ценой усложнения логики контроля целостности.

    Зоны разные территориально, в каждой свои магазины и склады.

    Зона поставок вообще не сущность. Это атрибут места хранения - обычная справочная надгруппа.
    Написано
  • Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

    @Akina
    Filarru, я на 100% согласен с Everything_is_bad. Магазин и Склад - это одна и та же сущность "Место, где хранится товар". Да, они различаются атрибутами - но не более. То же относится и к "Товар на складе" и "Товар в магазине" - это по смыслу вообще не сущность, а Junction table, пусть и с дополнительными атрибутами. И в первую голову надо переделывать схему.

    Что же до "пересечения" - я лично его в упор не вижу. Зато я вижу, что эта схема совершенно не позволяет выполнять контроль непротиворечивости данных на уровне БД. Причина чему - явная избыточность данных. Как по мне, следует вообще всё это потереть и начать заново, но начать с нормального анализа предметной области. И базовой сущностью при этом анализе должен быть квант товара, а вовсе даже не места хранения и не выполняемые с товаром операции. Сами же склады и магазины - это вообще вторичные контейнеры, выполняющие логическую группировку экземпляров основной сущности.
    Написано
  • Почему не получаются значения NEW в триггере BEFORE UPDATE?

    @Akina
    Это то что пишу в триггере:
    SELECT number INTO num FROM phone_item_number_1 WHERE item_id = id;
    INSERT INTO object_param_value_text (object_id, param_id, value) VALUES (NEW.object_id, 1, num);

    Ну вообще-то это можно делать и в один INSERT .. SELECT запрос - но при условии, что запись в phone_item_number_1 уже существует, и при этом строго одна:
    INSERT INTO object_param_value_text (object_id, param_id, value) 
    SELECT NEW.object_id, 1, number FROM phone_item_number_1 WHERE item_id = id;

    Тут есть проблемы. Если запись отсутствует - ничего не вставится. Если их более одной - вставится несколько строк.
    Можно использовать иначе:
    INSERT INTO object_param_value_text (object_id, param_id, value) VALUES 
    (NEW.object_id, 1, (SELECT number FROM phone_item_number_1 WHERE item_id = id));

    Тут при отсутствии записей будет вставлена одна запись с NULL. Но при наличии нескольких записей будет ошибка.

    -----------------

    Я что-то совсем потерялся в происходящем.

    Есть таблица Договоров. Есть таблица Объектов. Как я понимаю, записи в каждой из таблиц создаются совершенно независимо. Однако в таблице Договоров есть поле связи/ссылки с Объектом (договор может ссылаться только на один Объект, или ни на один). Значение в этом поле может либо присваиваться в момент создания записи при INSERT, либо указываться в дальнейшем при UPDATE. По-моему, так.

    Вы показываете схему, в которой присутствует аж 4 таблицы. И вот я не до конца понимаю привязки. Что из них таблица объектов? что таблица договоров? где поле связи (я не вижу внешних ключей)? каково назначение остальных двух таблиц?

    На будущее рекомендация: если поле в таблице А ссылается на поле в таблице Б (пусть даже без внешнего ключа, клиентской логикой) - делайте этим полям абсолютно одинаковые имена, понятно, уникальные в пределах схемы. Потом проще разбираться. Да и синтаксис JOIN USING прозрачнее и понятнее, чем JOIN ON.

    А теперь к логике.

    Создаётся Договор - запись в таблице ???. В ней есть поле ???, которое может быть ссылкой на Объект. Сам объект хранится в таблице ???, соответствующее поле для связи ???. (для оставшихся двух таблиц) Таблица ??? содержит ??? для таблицы ???, связывание происходит по выражению ???.??? = ???.??? - вот как-то так.

    Если в таблице Объект уже имеется запись, и в поле таблицы Договоров при вставке новой записи (INSERT) должна быть вставлена ссылка, то запись, из которой берётся значение для ссылки, берётся по выражению ???.??? = ???.???

    Если такая ссылка в таблицу Договоров добавляется уже в существующую запись (UPDATE), то запись в таблице Объектов, из которой следует взять значение поля ???, берётся по выражению ???.??? = ???.???

    Задача создаваемого триггера, определяемого на таблице ??? при выполнении операции ??? состоит в том, чтобы получить значение поля ??? из таблицы ??? и записать его в поле ??? таблицы ???
    Написано
  • Как заблокировать данные за предыдущий день?

    @Akina
    Требуется в конце каждого дня "замораживать данные" за каждый пройденный день

    Если надо замораживать только срез данных на конец дня, то лучше копировать этот срез в отдельную таблицу.
    Если надо сохранять состояние всего массива данных, то поможет только timeline (т.е. данные только добавляются, никаких изменений и удалений).
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Pro_Hacker, угу, можно... но в MySQL это либо стопицот функциональных индексов, либо фуллскан.
    Написано
  • Можно ли такое реализовать с помощью MySQL?

    @Akina
    Дмитрий Беляев, ну да. Во втором варианте предлагается разреженная таблица. Но её использование никоим боком не денормализация - как бы ни различались экземпляры разных типов, это всё одна и та же сущность.
    Написано